Add `nimare_version` attribute to all classes

[tsalo]

Summary

NiMARE classes (especially Datasets) are going to be in flux a bit until we've moved onto stable versions. This has caused problems in the past, so it would be helpful to retain a version string in the objects as an attribute.

Additional details

It would mainly be helpful for debugging. We could even add a method that checks input object versions against Estimator or Transformer versions and raise a warning if there's a mismatch.

Next steps

1. Add an attribute to the NiMARE base class that is determined at initialization based on the package version.
2. Check the attribute in Estimators and Transformers at fit/transform and raise a warning if there's a mismatch.

[tsalo]

@adelavega @jdkent @JulioAPeraza do you think this is something worth doing? Since we're going to start using NIMADS soon, we might want to have a nimads_version attribute as well, but this isn't something I've seen in other packages, so I wonder if it's a good idea.

[adelavega]

I suppose if this is just pulled from the package that it should be fairly harmless.

That said, I'm not entirely sure when you'd have access to a class object but not the main package import to check the version. I think adding a nimads_version to the package as a whole makes sense though.

[tsalo]

That said, I'm not entirely sure when you'd have access to a class object but not the main package import to check the version.

My main concern is making Datasets and fitted Estimators portable. Users may want to share their Dataset files, and it would be good to have some kind of warning if the objects will be incompatible across versions.

[adelavega]

Ah, gotcha. I think when saving out the object it certainly makes sense to annotate it w/ nimads/nimare versions.

However, when loading from file (for example, creating a Dataset object from a nimads file), couldn't we handle incompatibility upon loading? That is, if you try to load a nimads file that is too old, it either should throw an error or convert it on the fly to the internal representation. Hopefully if its just a reorganization, it can do that seamlessly and if you choose to save again it would do it in the new format.

Unless you're talking about pickling objects?

I'm less clear what saved fitted Estimators look like, and why those need to be saved, and in what format (rather than just re-run w/ same parameters in new version).

[JulioAPeraza]

Scikit-learn uses this https://scikit-learn.org/stable/modules/generated/sklearn.exceptions.InconsistentVersionWarning.html to raise a warning when an object is unpickled with a different version. We can do something similar to this in the NiMAREBase class.