Skip to content
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

Merged
merged 2 commits into from
Jan 26, 2024

Conversation

shabanzd
Copy link
Contributor

@shabanzd shabanzd commented Dec 24, 2023

This will allow a root module using a python version other than 3.11 to use the rules_appimage

@shabanzd shabanzd marked this pull request as ready for review December 24, 2023 21:45
@lalten
Copy link
Owner

lalten commented Dec 27, 2023

Would bazelbuild/rules_python#1642 fix this?

@ziad-fernride
Copy link

ziad-fernride commented Dec 28, 2023

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.
While here I am trying to allow root modules with python versions other than 3.11 to be able to use the rules_appimage.

@ziad-fernride ziad-fernride mentioned this pull request Dec 28, 2023
Comment on lines +26 to +31
PYTHON_VERSIONS = [
"3.8",
"3.9",
"3.10",
"3.11",
]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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(
Copy link
Owner

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Comment on lines +45 to +52
[
pip.parse(
hub_name = "rules_appimage_py_deps",
python_version = python_version,
requirements_lock = "//:requirements.txt",
)
for python_version in PYTHON_VERSIONS
]
Copy link
Owner

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.

Copy link
Contributor Author

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.

@lalten lalten merged commit 410932a into lalten:main Jan 26, 2024
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants