You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently everyone who wants to use this package is force to use urllib < 2.0.0 which is a version although receiving security patches that doesn't play well with cloud environments (e.g. Cloud Composer).
What feature would you like to see?
Since this is an artificial limit to only support engine my suggestion would be to create a feature package (pipeline-components[app-engine], kfp[app-engine]) to support this one use-case instead of generalising it on all pain ponts
What is the use case or pain point?
We publish packages based on cloud composer requirements and this is essentially blocking dependency resolution.
Is there a workaround currently?
I'm preparing a PR that tries to solve this, but essentially short of forking this project the above approach seems a bit more reasonable
I would also like to understand why the monkeypatching is needed, and if it can be solved in a simpler way
we are also aware that we could run this in a PythonVirtualEnvironmentOperator but ideally we want to abstract this away to deferable operators in our own package
Love this idea? Give it a 👍.
The text was updated successfully, but these errors were encountered:
Feature Area
Requirements:
Currently everyone who wants to use this package is force to use urllib < 2.0.0 which is a version although receiving security patches that doesn't play well with cloud environments (e.g.
Cloud Composer
).What feature would you like to see?
Since this is an artificial limit to only support engine my suggestion would be to create a feature package (pipeline-components[app-engine], kfp[app-engine]) to support this one use-case instead of generalising it on all pain ponts
What is the use case or pain point?
We publish packages based on cloud composer requirements and this is essentially blocking dependency resolution.
Is there a workaround currently?
I'm preparing a PR that tries to solve this, but essentially short of forking this project the above approach seems a bit more reasonable
I would also like to understand why the monkeypatching is needed, and if it can be solved in a simpler way
we are also aware that we could run this in a
PythonVirtualEnvironmentOperator
but ideally we want to abstract this away to deferable operators in our own packageLove this idea? Give it a 👍.
The text was updated successfully, but these errors were encountered: