-
Notifications
You must be signed in to change notification settings - Fork 542
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
cycles between torch 2.0.0 and triton 2.0.0 #1188
Comments
This is potentially a duplicate of #1076. |
@qzmfranklin do we have a circular dependency? I know they are allowed in Python, but bazel does not, at this point, allow for them. I am thinking you may want to see if torch and triton are addressing this. |
In the last wave of providers apache#31416 we bumped min-airlfow-version to 2.4 and added mechanism to verify min-airflow version is ok while importing, but it turned out that there are cases where installing just old version of airflow (with no constraints) brings the latest version of those providers and causes new installation of airflow to fail. This is far too common to ignore or require to use constraints, unfortunately We do not have min-airlfow-version in the preinstalled providers for one reason only. For some tools that are NOT conforming to standards (such as bazel), having min-airflow-version for those providers causes circular dependency (even though technically dependencies in PyPI can - and often are - circular, because dependencies in Python are not DAG and can contain cycles. This was in response to this issue in 2021 apache#17795. However, this is really bazel issue, and on top of it - it's recognized as such and being fixed very recently in bazelbuild/rules_python#1188 because there are other packages that have similar problems (pytorch and triton being popular couple). Also Bazel is not that popular in the Python world. Therefore, rather than trying to workaround the problem of bazel, we encourage them to merge and release the fix bazelbuild/rules_python#1166 (comment) and call it out in our installation instructions, that bazel installation might lead to problems like that. If bazel does not fix it, this will only be a problem for Future installations of airflow in a few months most likely. It will not impact current bazel users installing old versions of Airflow (actually they might start having problems now if we do not fix it and yank the 5 providers released yesterday)
In the last wave of providers #31416 we bumped min-airlfow-version to 2.4 and added mechanism to verify min-airflow version is ok while importing, but it turned out that there are cases where installing just old version of airflow (with no constraints) brings the latest version of those providers and causes new installation of airflow to fail. This is far too common to ignore or require to use constraints, unfortunately We do not have min-airlfow-version in the preinstalled providers for one reason only. For some tools that are NOT conforming to standards (such as bazel), having min-airflow-version for those providers causes circular dependency (even though technically dependencies in PyPI can - and often are - circular, because dependencies in Python are not DAG and can contain cycles. This was in response to this issue in 2021 #17795. However, this is really bazel issue, and on top of it - it's recognized as such and being fixed very recently in bazelbuild/rules_python#1188 because there are other packages that have similar problems (pytorch and triton being popular couple). Also Bazel is not that popular in the Python world. Therefore, rather than trying to workaround the problem of bazel, we encourage them to merge and release the fix bazelbuild/rules_python#1166 (comment) and call it out in our installation instructions, that bazel installation might lead to problems like that. If bazel does not fix it, this will only be a problem for Future installations of airflow in a few months most likely. It will not impact current bazel users installing old versions of Airflow (actually they might start having problems now if we do not fix it and yank the 5 providers released yesterday)
Had the same issue with pytorch2.0 / triton and resolved this by patching the triton wheel to remove the pytorch-dependency from it (resolving the circular dependency affecting the bazel-side) |
In the last wave of providers #31416 we bumped min-airlfow-version to 2.4 and added mechanism to verify min-airflow version is ok while importing, but it turned out that there are cases where installing just old version of airflow (with no constraints) brings the latest version of those providers and causes new installation of airflow to fail. This is far too common to ignore or require to use constraints, unfortunately We do not have min-airlfow-version in the preinstalled providers for one reason only. For some tools that are NOT conforming to standards (such as bazel), having min-airflow-version for those providers causes circular dependency (even though technically dependencies in PyPI can - and often are - circular, because dependencies in Python are not DAG and can contain cycles. This was in response to this issue in 2021 #17795. However, this is really bazel issue, and on top of it - it's recognized as such and being fixed very recently in bazelbuild/rules_python#1188 because there are other packages that have similar problems (pytorch and triton being popular couple). Also Bazel is not that popular in the Python world. Therefore, rather than trying to workaround the problem of bazel, we encourage them to merge and release the fix bazelbuild/rules_python#1166 (comment) and call it out in our installation instructions, that bazel installation might lead to problems like that. If bazel does not fix it, this will only be a problem for Future installations of airflow in a few months most likely. It will not impact current bazel users installing old versions of Airflow (actually they might start having problems now if we do not fix it and yank the 5 providers released yesterday) GitOrigin-RevId: 547e352578fac92f072b269dc257d21cdc279d97
Closing this as a duplicate of #1076 For what it's worth, there are workarounds for the torch / triton situation that may be suitable for anyone on this issue: pytorch/pytorch#99622 (comment) |
This patch reworks the `pip_repository` machinery to allow users to manually annotate groups of libraries which form packaging cycles in PyPi and must be simultaneously installed. The strategy here is to transform any dependencies `A` and `B` which have dependencies and are mutually dependent ```mermaid graph LR; A-->B; A-->D; A-->E; B-->A; B-->F; B-->G; ``` into a new "dependency group" `C` which has `A*` and `B*` as dependencies, defined as `A` and `B` less any direct dependencies which are members of the group. This is viable _for python_ because Python files just need to be emplaced into a runfiles directory for the interpreter. We don't actually have a true hard dependency between the build definition of `A` requiring the build product `B` be available which requires that the build product of `A` be available. ```mermaid graph LR C-->A*; A*-->D; A*-->E; C-->B*; B*-->F; B*-->G; ``` This gets us most of the way there, as a user can now safely write `requirement("A")` and we can provide them with `C`, which has the desired effect of pulling in `A`, `B` and their respective transitives. There is one remaining problem - a user writing `deps = [requirement("A"), requirement("B")]` will take a double direct dependency on `C`. So we need to insert a layer of indirection, generating `C_A` and `C_B` which serve only as unique aliases for `C` so that we can support the double dependency. Our final dependency graph then is as follows ```mermaid graph LR C_A-->C; C_B-->C; C-->A*; A*-->D; A*-->E; C-->B*; B*-->F; B*-->G; ``` Addresses #1076, #1188 ## To do - [x] Get rebased - [x] Get re-validated manually - [x] Buildifier - [x] Get CI happy - [x] Update documentation - [x] Update changelog --------- Co-authored-by: Ignas Anikevicius <[email protected]>
In the last wave of providers #31416 we bumped min-airlfow-version to 2.4 and added mechanism to verify min-airflow version is ok while importing, but it turned out that there are cases where installing just old version of airflow (with no constraints) brings the latest version of those providers and causes new installation of airflow to fail. This is far too common to ignore or require to use constraints, unfortunately We do not have min-airlfow-version in the preinstalled providers for one reason only. For some tools that are NOT conforming to standards (such as bazel), having min-airflow-version for those providers causes circular dependency (even though technically dependencies in PyPI can - and often are - circular, because dependencies in Python are not DAG and can contain cycles. This was in response to this issue in 2021 #17795. However, this is really bazel issue, and on top of it - it's recognized as such and being fixed very recently in bazelbuild/rules_python#1188 because there are other packages that have similar problems (pytorch and triton being popular couple). Also Bazel is not that popular in the Python world. Therefore, rather than trying to workaround the problem of bazel, we encourage them to merge and release the fix bazelbuild/rules_python#1166 (comment) and call it out in our installation instructions, that bazel installation might lead to problems like that. If bazel does not fix it, this will only be a problem for Future installations of airflow in a few months most likely. It will not impact current bazel users installing old versions of Airflow (actually they might start having problems now if we do not fix it and yank the 5 providers released yesterday) GitOrigin-RevId: 547e352578fac92f072b269dc257d21cdc279d97
In the last wave of providers #31416 we bumped min-airlfow-version to 2.4 and added mechanism to verify min-airflow version is ok while importing, but it turned out that there are cases where installing just old version of airflow (with no constraints) brings the latest version of those providers and causes new installation of airflow to fail. This is far too common to ignore or require to use constraints, unfortunately We do not have min-airlfow-version in the preinstalled providers for one reason only. For some tools that are NOT conforming to standards (such as bazel), having min-airflow-version for those providers causes circular dependency (even though technically dependencies in PyPI can - and often are - circular, because dependencies in Python are not DAG and can contain cycles. This was in response to this issue in 2021 #17795. However, this is really bazel issue, and on top of it - it's recognized as such and being fixed very recently in bazelbuild/rules_python#1188 because there are other packages that have similar problems (pytorch and triton being popular couple). Also Bazel is not that popular in the Python world. Therefore, rather than trying to workaround the problem of bazel, we encourage them to merge and release the fix bazelbuild/rules_python#1166 (comment) and call it out in our installation instructions, that bazel installation might lead to problems like that. If bazel does not fix it, this will only be a problem for Future installations of airflow in a few months most likely. It will not impact current bazel users installing old versions of Airflow (actually they might start having problems now if we do not fix it and yank the 5 providers released yesterday) GitOrigin-RevId: 547e352578fac92f072b269dc257d21cdc279d97
In the last wave of providers #31416 we bumped min-airlfow-version to 2.4 and added mechanism to verify min-airflow version is ok while importing, but it turned out that there are cases where installing just old version of airflow (with no constraints) brings the latest version of those providers and causes new installation of airflow to fail. This is far too common to ignore or require to use constraints, unfortunately We do not have min-airlfow-version in the preinstalled providers for one reason only. For some tools that are NOT conforming to standards (such as bazel), having min-airflow-version for those providers causes circular dependency (even though technically dependencies in PyPI can - and often are - circular, because dependencies in Python are not DAG and can contain cycles. This was in response to this issue in 2021 #17795. However, this is really bazel issue, and on top of it - it's recognized as such and being fixed very recently in bazelbuild/rules_python#1188 because there are other packages that have similar problems (pytorch and triton being popular couple). Also Bazel is not that popular in the Python world. Therefore, rather than trying to workaround the problem of bazel, we encourage them to merge and release the fix bazelbuild/rules_python#1166 (comment) and call it out in our installation instructions, that bazel installation might lead to problems like that. If bazel does not fix it, this will only be a problem for Future installations of airflow in a few months most likely. It will not impact current bazel users installing old versions of Airflow (actually they might start having problems now if we do not fix it and yank the 5 providers released yesterday) GitOrigin-RevId: 547e352578fac92f072b269dc257d21cdc279d97
Thanks a lot for all the great work put in rules_python.
I really enjoyed the multi-version and vendored toolchain support.
Ran into a cycled dependency issue, as follows:
bazel: 6.1.1 (though I don' this this is relevant)
rules_python: a recent HEAD (1e869d8)
repro:
WORKSPACE:
requirements.in:
Run
yields the following error:
A quick
fix
for me would be to remove the dependency oftorch
fromtriton
. Afterall,triton
only depends ontorch
for testing. It's optional.I looked around and found
package_annotation
. But it does not allow removing an edge.I also found that the
wheel_installer.py
already removed self-edge. But it does not remove cycles in the general case. Understandable, it's awheel_installer
, not awheels_installer
.I think the fundamental issue is that
wheel_installer
includes all dependencies instead of just the core dependencies.What would be a suggested fix from rules_python's authors for the situation I'm in?
The text was updated successfully, but these errors were encountered: