Closed dotsdl closed 9 months ago
Note that there's already a _schema_version
for each object. See https://github.com/OpenFreeEnergy/gufe/pull/227. This is an object-specific version, specifically with the idea that it will handle serialization migrations. I can imagine use cases where __module_version__
provides other/easier to use information (might be harder to map the integer _schema_version
to versions of software). However, let's try to avoid maintaining two mechanisms to solve the same problem.
We currently include
__qualname__
and__module__
in thedict
,shallow_dict
, andkeyed_dict
representations of anyGufeTokenizable
. These are necessary for re-instantiating aGufeTokenizable
from these forms, identifying the class and source module to use.In discussion with @ianmkenney this morning, we thought it may be useful for a variety of downstream uses to also include a
__module_version__
item in these*dict
forms, giving the version of the__module__
that created this form of the object. This would give agufe
-supported way to e.g. check for version mismatches between a serializedProtocol
and the version of the corresponding module on a remote executor (such as inalchemiscale
).We could not think of any substantial drawbacks to including
__module_version__
, other than slightly increasing the size of these objects and their serialized forms.@ianmkenney can you elaborate on your thinking here as well?