-
Notifications
You must be signed in to change notification settings - Fork 442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Model links lazy evaluation in pipeline code #2205
Model links lazy evaluation in pipeline code #2205
Conversation
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
Important Auto Review SkippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the To trigger a single review, invoke the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
E2E template updates in |
…ion-in-pipeline-code
…ion-in-pipeline-code
…ion-in-pipeline-code
…ion-in-pipeline-code
tests/integration/functional/pipelines/test_pipeline_context.py
Outdated
Show resolved
Hide resolved
Co-authored-by: Alex Strick van Linschoten <[email protected]>
…e-code' of https://github.com/zenml-io/zenml into feature/OSS-2713-model-links-lazy-evaluation-in-pipeline-code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙏🏻
src/zenml/metadata/lazy_load.py
Outdated
from zenml.models import RunMetadataResponse | ||
|
||
return RunMetadataResponse( | ||
id=uuid4(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you already pointed out in the PR description, not a huge fan of this. I don't think we can easily remove that from the BaseResponse
class (for our actual responses, we do always want the ID to be in there). There's also a problem when users in their pipeline function try to access any properties of the lazy responses, they will get random values or strange error messages.
At least the error messages we could prevent by maybe having a separate subclass for it, but not convinced this is a good idea..
class LazyArtifactVersionResponse(ArtifactVersionResponse):
_lazy_load_name: Optional[str] = None
_lazy_load_version: Optional[str] = None
_lazy_load_model_version: Optional["ModelVersion"] = None
# We should probably do this for all properties, otherwise users will run into strange error message when they
# try to access any of those on a lazy object
@property
def id(self) -> UUID:
raise RuntimeError("ID can't be accessed for lazy AVR")
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually instead of overwriting all properties, we probably only need to overwrite the get_body()
and get_metadata()
functions to raise errors which describe the issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super, thanks!
Thanks a lot @schustmi - a golden review 👍🏼 You solved all design issues with one shot. Please read it again once CI passes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree to the overall solution of passing references to model versions and artifacts at pipeline compilation time and deferring their resolution at pipeline execution time. I can't say I fully understand all the implications of this, given that I'm not familiar with this area of code. Good to go from my end.
…ion-in-pipeline-code
* MV data lazy loading in pipelines * add tests * new template ref * use `BaseModel` * Auto-update of Starter template * update to `v7` syntax * update test signatures * Auto-update of E2E template * update test signatures * wandb lint * lint * remove leftover * Apply suggestions from code review Co-authored-by: Alex Strick van Linschoten <[email protected]> * renaming * model lazy load in `model` * metadata lazy load in `metadata` * implement Michael's suggestions --------- Co-authored-by: GitHub Actions <[email protected]> Co-authored-by: Alex Strick van Linschoten <[email protected]>
* MV data lazy loading in pipelines * add tests * new template ref * use `BaseModel` * Auto-update of Starter template * update to `v7` syntax * update test signatures * Auto-update of E2E template * update test signatures * wandb lint * lint * remove leftover * Apply suggestions from code review Co-authored-by: Alex Strick van Linschoten <[email protected]> * renaming * model lazy load in `model` * metadata lazy load in `metadata` * implement Michael's suggestions --------- Co-authored-by: GitHub Actions <[email protected]> Co-authored-by: Alex Strick van Linschoten <[email protected]>
Describe changes
I implemented the ability to do lazy loading of Artifact Version, Artifact Version Metadata, and Model Version Metadata inside the pipeline body. The following syntax will evaluate objects only during pipeline execution (before it was fixed on pipeline compilation):
Side changes:
log_model_version_metadata
is now listed on root level (from zenml import log_model_version_metadata
)Side breaking change:
metdata
andrun_metadata
across Artifact and Model Versions:ModelVersion().metadata
becomesModelVersion().run_metadata
Pre-requisites
Please ensure you have done the following:
develop
and the open PR is targetingdevelop
. If your branch wasn't based on develop read Contribution guide on rebasing branch to develop.Types of changes