Torch/TorchGeo Export & Packaging

[isaaccorley]

Description

This PR adds functions for exporting and packaging a torch (in this example, TorchGeo) model and transforms along with model metadata that is compliant with the MLM schema into a single .pt2 archive.

This currently depends on the torch 2.8 pre-release of PyTorch scheduled to be released early next month.

Related Issue

N/A

Type of Change

• 📚 Examples, docs, tutorials or dependencies update;
• 🔧 Bug fix (non-breaking change which fixes an issue);
• 🥂 Improvement (non-breaking change which improves an existing feature);
• 🚀 New feature (non-breaking change which adds functionality);
• 💥 Breaking change (fix or feature that would cause existing functionality to change);
• 🔐 Security fix.

Checklist

• I've read the CONTRIBUTING.md guide;
• I've updated the CHANGELOG.md with provided changes;
• I've updated the README.md and/or
  best-practices.md as applicable with new features;
• I've updated the code style using make check;
• [ X] I've written tests for all new methods and classes that I created;
• I've written the docstring in Google format for all the methods and classes that I used.

[fmigneault]

@rbavery @isaaccorley
Sorry I did not have this realization sooner, but I think this reason (#95 (comment)) is a strong justification why exported MLM metadata should be nested under properties. Not having a $schema reference would eventually make it very hard to figure out where/how a certain YAML MLM-metadata file was actually generated, or with which stac_model version to reload it, in order to replicate the result. The more MLM gets adopted, the more we will see varying definitions generated at different moment, and we won't be able to reliably resolve the metadata version otherwise.

[rbavery]

Could we instead have a schema reference without the nesting of properties to save us a field and level of nesting?

I think your reasoning makes sense on keeping the validation path the same whether it is done with pydantic or pystac, and accommodating more complex references to other stac extensions.

the extra tabs/spaces and extra field is a bit unfortunate for the use cases that don't need these more complex references but probably worth it.

[isaaccorley]

I've updated the pyproject.toml with torch as optional dependencies. However one issue I had was the latest version of TorchGeo deprecated Python 3.10 support so now only supports python>=3.11. I had to change this in pyproject.toml to support TorchGeo as a dependency and it reformatted quite a few things so apologies for the messy PR.

[fmigneault]

I think is looks pretty good and almost ready to merge.
Just waiting on remaining threads to be resolved to proceed.

[fmigneault]

Note:
Another reason why I prefer to leave torchgeo in is that we are going to need it anyway for #102, but I think the way that it gets added here is better given that it considers CPU/GPU index.