feat(l2gmodel): store features list metadata as instance attribute

[ireneisdoomed]

✨ Context

The list of features that the L2G model has been trained on is a crucial part of the model metadata. The order in which those features have to be passed to be model is also important and shall be maintained so that L2G produces accurate results.

To accomplish this, I've added a new instance attribute features_list to the LocusToGeneModel class. Any method that needs this information will fetch it now from the model's metadata, not from the step config.

This is to avoid incompatibilities between the list of features provided in the package config and older versions of the model.

This PR was motivated by an issue observed in #939

🛠 What does this PR implement

• Addition of LocusToGeneModel.features_list as instance attribute.
• Everytime a model is loaded, this attribute has to be populated. Now, there are 2 ways to load a model:
  1. From the Hub. The feature list is model metadata, so the list is loaded from this metadata. This is the preferred method, because it ensures that the list of features match the ones during training
  2. From a file. Here we lack that metadata, so we populate the default list from the config, which could have backwards compatibility issues.
• The features_list parameter from the config is then used:
  1. In the training step, to select features to include
  2. In the predicition step, only if the model is not loaded from the Hub

🙈 Missing

🚦 Before submitting

• Do these changes cover one single feature (one change at a time)?
• Did you read the contributor guideline?
• Did you make sure to update the documentation with your changes?
• Did you make sure there is no commented out code in this PR?
• Did you follow conventional commits standards in PR title and commit messages?
• Did you make sure the branch is up-to-date with the dev branch?
• Did you write any new necessary tests?
• Did you make sure the changes pass local tests (make test)?
• Did you make sure the changes pass pre-commit rules (e.g uv run pre-commit run --all-files)?

[project-defiant]

Is it the artifact from the .pre-commit update?

[project-defiant]

To sum up of what I understood:
The feature_list is derived from the config.json file generated for the model in the repository.

This is a correct approach from what I can read from the skops package documentation. The only inconvenience is (as you have mentioned), when someone wants to use the older model, then they must provide the features list to use.

Two additional points:

• This is a great approach, moreover I would also allow the user to add the config.json in the skops format, since they are responsible for running the model predictions, hence they should make sure that the feature_list is correct.
• Not sure if it already is in the place but, make sure that all of the features are in the FM and in correct order provided by the user (or metadata).

I wonder if we could make an update to the skops to allow for referencing model by the commit. Mayby it is a good time to make this as a suggestion in the issue ?

I can take a look in free time next week.

[ireneisdoomed]

Ty for the comments!

I wonder if we could make an update to the skops to allow for referencing model by the commit

That would be nice, but loading a model that is not downloaded from the Hub would still have the issue. I think that your suggestion of adding a model metadata when we dump the model is good!