-
Notifications
You must be signed in to change notification settings - Fork 8
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
support root modules using python 3.8 #115
Conversation
9e446fb
to
c9fe4c5
Compare
Would bazelbuild/rules_python#1642 fix this? |
bazelbuild/rules_python#1642 is related to: bazelbuild/bazel-central-registry#1198 (comment) ... The issue there is related to whether or not is_default is picked up, which is making one of the presubmit tests fail. |
PYTHON_VERSIONS = [ | ||
"3.8", | ||
"3.9", | ||
"3.10", | ||
"3.11", | ||
] |
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.
Wouldn't this have to match all the versions in
https://github.com/bazelbuild/rules_python/blob/4c2d7d9d6608795522322a9b2294b5053e41b979/python/versions.bzl#L47-L48
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 far as I understand, this is not really about toolchains. It is about pip wheels. The pip wheels need to be registered for all python versions to be supported. I am not sure if those wheels really care about the patch version of python.
python.toolchain(python_version = "3.11") | ||
|
||
[ | ||
python.toolchain( |
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.
Will this download all the actual Python toolchains to the repo cache?
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.
Hopefully not 😂
If it does, I would assume it is a bug.
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.
Of course here I am talking about the root module. The rules_appimage will hopefully not bring in any toolchain other than the one requested by the root module.
[ | ||
pip.parse( | ||
hub_name = "rules_appimage_py_deps", | ||
python_version = python_version, | ||
requirements_lock = "//:requirements.txt", | ||
) | ||
for python_version in PYTHON_VERSIONS | ||
] |
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.
Such a change would have to be reflected in the WORKSPACE setup I think? The Bzlmod and Workspace implementations should not diverge.
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.
This problem does not exist in the WORKSPACE world since every dependency brings its own transitive dependency graph. Meaning that the WORKSPACE will always use python 3.11 (which is the default in the MODULE.bazel). I think that's close enough 😂
The problem is only in the bzlmod world, where only 1 transitive dependency graph is resolved for the entire project. Which is super cool, but comes with some costs.
I am not sure this PR is the only way to handle it, but I already saw some modules in the BCR that take this approach, and I find it logical.
This will allow a root module using a python version other than 3.11 to use the rules_appimage