-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
prefect deploy
command fails if not all dependencies are present at runtime
#9512
Comments
We think we need to load the flow to generate the OpenAPI schema for its parameters. We could do this at an earlier time and store the schema JSON somewhere? |
This issue is stale because it has been open 30 days with no activity. To keep this issue open remove stale label or comment. |
This issue is stale because it has been open 30 days with no activity. To keep this issue open remove stale label or comment. |
+1 on this - Using both the previous deployment.apply() and currently |
+1 on this. |
+1 on this. On CI/CD waste a lot of time to install dependencies which already installed on Docker image (for example) |
Would love to see this behavior changed. My initial understanding of the My workaround will be to install flows in my CI/CD environment, and to have a separate build action for each flow, but this not ideal from a code hygiene and performance perspective. |
Any updates on this issue? Having to install all dependencies to create a simple deployment object is kind of cumbersome and conflicts with the purpose of separating flow's dependencies using different images. |
Here too. I use PIpfile with pipenv to ensure all works properly. Dockerfile (image where run flow)
CI/CD (GitHub Actions)
So, I ensure that CI/CD needs the requirements like Dockerfile where build a flow image. |
+1 on this. Currently I deal with that by calling the external packages only inside functions. |
+1 on this. |
Thank you for all the +1. We'll look more into this. |
adding another +1 |
it is so frustrating issue.. |
+1 |
Hi all, this will probably not get into tomorrow's release of 2.19.3, but hopefully one very soon! Thanks to @desertaxle for this |
+1 |
@jamiezieziula @prefectcboyd @ne-warwick @ialejandro @speedyturkey @furkanrollic @pierreloicq @netanelm-upstream @yuriy-arabskyy @tourist @cvvs @MartijnvanElferen @baxen @akfmdl @syakesaba @josefondrej @ChrisPaul33 @nicelgueta @Mdanford97 This will be available after today's release of Edit: Released |
Thank you so much. https://zenn.dev/syakesaba/articles/prefect_2_19_3 but I realize that some flow not recognized when that is asyncsonized like this. @flow
async def main(): any ideas? ty |
@syakesaba I think this was fixed in a subsequent PR |
Thank you so much that was fixed! |
@serinamarie This issue occurs again at version > 2.20.2 |
hi @akfmdl - can you explain more what you tried and what you're seeing? the issue (as expressed here) should be solved as of 2.20.2 but its possible there's an edge case you're hitting |
@zzstoatzz I was testing prefect deploy with some dependencies missing locally. Before version
The deployment worked without dependencies from version Starting from version UPD: I also checked v. 3.0 but I still din't work for me |
In v3.0, I still get an error if I use a missing import in a callback. from my.callbacks import test_callback
@flow(name="test", on_running=[test_callback]) |
First check
Prefect Version
2.x
Describe the current behavior
Currently, running
prefect deploy...
will fail if not all dependencies required by the deployments are present:This can be problematic if deploying multiple flows that have different requirements / when using virtual environments to isolate dependencies. This also makes deploying via cicd cumbersome because, again, all dependencies need to be present (which is duplicative of something like a docker build step)
Describe the proposed behavior
The
prefect deploy
command would not require all dependencies to be present at runtime (either optionally or by default)Example Use
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: