Downloading pre-trained models

[PicoCentauri]

A very nice feature would be able to download pre-trained models. To implement this the already existing export CLI command can be very nicely extended. The current API is

mtt export \
   experimental.pet \
   local-file.pt \
   -o my-exported-model.pt

To address the ability for downloading, we will extend the API of export to pass local files and URLs as

mtt export \
   experimental.pet \
   https://domain.org/best-model-ever.pt \
   -o my-exported-model.pt

---

On top we will improve/add a Python API allow calling

from metatrain import export

model = export(
    architecture_name="experimental.pet",
    path="https://domain.org/best-model-ever.pt",
)

We may in the future allow more extended exporting using an options.yaml and curate fixed lists of named models. To prepare the API, we could already throw an error, if users try to pass something like mtt export experimental.pet options.yml.

---

[abmazitov]

@PicoCentauri and I had a small discussion of making the user experience as smooth as possible. Here are my thoughts on that, summarized

1. From the user point of view, there should be a single operation of importing the model, which calls the fetch function (or export function, depending on how we call it) if the model is not yet downloaded and cached, and returns a ready-to-use MetatensorAtomisticModel.
2. mtt export CLI command should indeed be called export, because it saves the model and it's extensions on disk
3. If we call the metatrain.export from python and not from CLI, it should also only save the data on disk, and should not provide you with a loaded model instance. Having model = export(...) to me looks a bit confusing, and the function name here should be different IMO. Something like model = fetch(...) or model = get_model(...) or model = load(...) should work better here.

[Luthaf]

3. [...] it should also only save the data on disk,

I think I would rather rename the function and make it return an instance of MetatensorAtomisticModel. get_model or load feels like the right kind of semantic here.