python311Packages.{jax,jaxlib,jaxlib-bin}: 0.4.28 -> 0.4.32 #318995
Conversation
|
I cannot get |
Could be due to this change: jax-ml/jax@jaxlib-v0.4.28...jaxlib-v0.4.29#diff-5493ff8e9397811510e780de47c57abb70137f1afe85d1519130dc3679d60ce5 |
GaetanLepage
changed the title
|
I updated to v0.4.30 which was released today. However, it crashes in a different way: |
|
The diff looks non-trivial: jax-ml/jax@jaxlib-v0.4.29...jaxlib-v0.4.30 |
| { x86_64-linux = ""; } | ||
| else | ||
| { | ||
| x86_64-linux = "sha256-uOoAyMBLHPX6jzdN43b5wZV5eW0yI8sCDD7BSX2h4oQ="; | ||
| aarch64-linux = "sha256-+SnGKY9LIT1Qhu/x6Uh7sHRaAEjlc//qyKj1m4t16PA="; | ||
| x86_64-linux = ""; | ||
| aarch64-linux = ""; |
There was a problem hiding this comment.
Yes, this is a WIP. I am stuck on #318995 (comment).
I will mark this PR as draft.
It looks like it has just run out of disk space, eg |
I'm afraid that there is a real issue unfortunately: |
|
what's the status of this? |
I'm stuck on this. We need to revisit the |
|
From a quick glance, I think jaxlib and tensorflow broke with this change: jax-ml/jax@517e299. I think this forces bazel to download a "hermetic" python which is basically some prebuilt binary of questionable origin. Looking at the build logs, it also chooses the python release "automatically" unless you export HERMETIC_PYTHON_VERSION. We want this feature off, random executables from the internet is not the kind of reproducibility Nixpkgs is after... Tracking upstream: jax-ml/jax#22216 (comment) @GaetanLepage can you try |
|
Hello @SomeoneSerge, We are sorry to hear that hermetic Python setup breaks your workflow . I would like to learn more about it, specifically if it is a technical breakage or more in the realm of depending on downloaded python being against your established policies. Either way, your issues could be solved without non-hermetic behavior (please check my response in jax/issues/22216 for details). Let me to address a few of the raised concerns directly in this thread
The downloaded Python interpreters are not of questionable origin and are not random at all. The actual packages to download, together with their SHA256 sums are specified directly in rules_python, which is an officially supported product. If you trust bazel to build your project (which must be the case here) you should trust rules_python as one of its core components as well. The actual python binaries used are based on https://github.com/indygreg/python-build-standalone, if that does not satisfy your standards, you may always provide your own python interpreter and exactly that one will be used in your build.
I would like to know more about how reproducibility is defined in Nixpkgs, but either way one of hermetic Python's major goals is to actually increase reproducibility. Hermetic Python locks all of the key dependencies together with their SHA256 sums, so entire Python ecosystem in the build is fully locked and remains the same regardless of the surrounding environment and depends only on the corresponnding git commit which updates/changes those dependencies directly in the source tree. Downloading anything from the internet in general. |
Thank you @vam-google for this very detailed answer. The answer to @SomeoneSerge's issue looks like a good starting point ! |
|
Thanks @vam-google for providing this info!
Nix has two types of build rules, called "derivations" in Nix parlance:
Our Bazel rule, Btw I will shamelessly take this opportunity to draw your attention to #321920 in which we have found that the output of the |
|
Thanks and welcome @vam-google! I'll try to be brief (EDIT: I failed) and not parrot what has already been said. Regarding "our workflow", my response1 in the jax repo touches on the subject a bit. What I didn't mention is parallel goals such as customization, inspectability, etc. There's some benefits we get from being able to make all of our software use exactly the same python interpreter arbitrarily customized at the user site. <HERE WAS A CHUNK OF TEXT REPEATING SAMUEL'S POST IN DIFFERENT WORDS> The removed piece:
(end of the removed piece)
I'd say it's both. I highlighted some of the technical aspects in the other response1, although I think that was just the first iteration. As for the policies, this has to do with your other question:
Some of our "derivations" are actually non-deterministic (parallelism, scheduling, etc) so it's more common that we'd talk about "repeatability"... but to really answer your question, I'd rather think in terms of "complexity" instead. In particular, the cost we must pay now to be able to bootstrap a piece of today's software from scratch, say, ten years later. In the first approximation (let's say, compatible hardware and such belong in the 0th), our main threat are these "FODs" that Samuel has mentioned, for two reasons: many of them are the roots of our dependency DAG (and all roots are FODs), and they also are impure (allowed network). Thus at the very least, one had better archived all of the FODs. Thus, we want fewer and smaller FODs. From this point of view, having a piece of source code as a root is preferable (less "complex") to having a collection of large non-inspectable platform-specific binaries. Our ideal would be a full-source bootstrap similar to what Guix does2, but there are tradeoffs involved and we currently make different choices. It was also in this limited sense that I called the downloaded binaries "questionable [in] origin" and "random" Footnotes |
wegank
added
the
2.status: merge conflict
ofborg
bot
removed
the
2.status: merge conflict
GaetanLepage
force-pushed
the
jax
branch
4 times, most recently
from
c8f4e2a to
9754cfa
Compare
GaetanLepage
changed the title
wegank
added
the
2.status: merge conflict
ofborg
bot
removed
the
2.status: merge conflict
|
Head's up: We're migrating to numpy 2.1 in #354627 and jax 0.4.28 is failing a number of tests on 3.12 and 3.13. |
|
Thanks for the heads up @mweinelt! Has anyone tried the suggestion in jax-ml/jax#22216 (comment) yet? If so, what was the result? |
wegank
added
the
2.status: merge conflict
ofborg
bot
removed
the
2.status: merge conflict
Description of changes
Changelogs:
cc @samuela
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.