rules_python
rules_python copied to clipboard
bazelbuild
chore: Bump deps
Bump deps with bazel run //tools/private/update_deps:update_pip_deps
FYI, the last time I did this we got a few regressions for pip compile. I'll dig for issues later.
cc @vam-google -- he's also interested in having the pip deps raised; it fixes something with freethreaded builds. Though he doesn't need as many bumped as far, see https://github.com/tensorflow/tensorflow/blob/master/third_party/py/rules_python1.patch
Thanks @rickeylev!
tl;dr; as long as pip is 24.0 rules_python does not fully support freethreaded python.
For the context: pip 24.0 (the one currently used in rules_python) is older than python 3.13 release. Pytnon 3.13 was the first release with free threading implemetnation, which itself gave birth of new class of python wheels with C++ extensions in it. Now there are two versions: cp313 and cp313t (for example numpy-2.2.5-cp313-cp313-manylinux_2_17_x86_64.manylinux2014_x86_64.whl and numpy-2.2.5-cp313-cp313t-manylinux_2_17_x86_64.manylinux2014_x86_64.whl).
Pip prior to 24.2 version does not see that difference and will try to install non-free threaded version of a package even if the free threaded version exists. This breaks JAX's freethreaded builds in particular (e.g. jaxlib-0.6.0-cp313-cp313t-manylinux2014_aarch64.whl).
That is why we patch rules_python. I'm currently in the process of updating our key deps, and for rules_python was hoping that 1.4.rc-1 would have pip already upgraded, but unfortunately it does not. If you can get this upgrade in it would be great for us and we would be able to stop patching rules_python. I want us to live close to rules_python head, but for that we need to get rid of patching (otherwise it is too much pain to upgrade)
FYI, the previous bump got reverted here: https://github.com/bazel-contrib/rules_python/pull/2584
It has the links to the issues that we encountered. See the comment: https://github.com/bazel-contrib/rules_python/issues/908#issuecomment-2612799169
Pip 25.1 was released https://pip.pypa.io/en/stable/news/#v25-1
So when the time comes to bump, we should aim for 25.1+
@aignas id correct that there are often quite a lot of bumpy regressions when upgrading these deps. So we should probably do it when we have no other major changes going on.
Regenerated the upgrades now. I'll leave it up to maintainers to decide when to merge
In order to be comfortable to merge this I would like to have a regression test for the #908 issue. And the CI ideally should not be failing due to the update. It seems that the most recent pip update is a little bit tough.
I think we can have a discussion again when to merge when the CI is green.
FWIW, if you bump pip-tools to >7.5.0 the absolute path issue should be resolved when using pip >24.3.
Issue: https://github.com/jazzband/pip-tools/issues/2131 Fix: https://github.com/jazzband/pip-tools/pull/2195
build constraints is now supported as part of pip 25.3 which may improve reproducibility of builds using sdist . https://github.com/pypa/pip/pull/13534
It seems that latest pip is incompatible with pip-tools: https://github.com/jazzband/pip-tools/issues/2252