Current behavior is to use standard serialization when saving artifacts. that almost always means that the data is being serialized with relative references to the source code. (ex pickle a class and load into a workspace with the source code deleted or unavailable)
This introduces potential drift concerns if the source code is altered when deserializing an artifact. (warning logic is implemented via library versions in metadata and using a version controlled source checked out according to the artifact ref is highly encouraged, but nothing is preventing the issue)
working thought:
use inspect to copy artifact source code on save
dynamically inject code on load into custom namespace
limitations:
only scalable to save artifact definition. references and other helpers can still drift
also potentially very janky.. more thought necessary to flesh this out
Current behavior is to use standard serialization when saving artifacts. that almost always means that the data is being serialized with relative references to the source code. (ex pickle a class and load into a workspace with the source code deleted or unavailable)
This introduces potential drift concerns if the source code is altered when deserializing an artifact. (warning logic is implemented via library versions in metadata and using a version controlled source checked out according to the artifact ref is highly encouraged, but nothing is preventing the issue)
working thought: use inspect to copy artifact source code on save
dynamically inject code on load into custom namespace
limitations: only scalable to save artifact definition. references and other helpers can still drift
also potentially very janky.. more thought necessary to flesh this out