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
wasmer: Add cargo hashes for Python 3.6/3.7/3.9 support #109039
wasmer: Add cargo hashes for Python 3.6/3.7/3.9 support #109039
Conversation
And what about python 3.7 and 3.9? |
e7d4028
to
6a881b3
Compare
6a881b3
to
d2ffdbc
Compare
latest commit is a slight code clean up to avoid the annoying if-else chain |
d2ffdbc
to
8f31eca
Compare
8f31eca
to
c2028d7
Compare
also use |
maintaining this is going to be difficult, is there a way we could have a script ran to generate the related hashes? |
@jonringer makes sense; are there any other examples in nixpkgs I may be able to look at for reference? I had just manually run something like this (actually opened in 4 terminals and ran in parallel)
and then just copy pasted the hashes in. It seems far easier to re-use nix's output than to independently figure out the cargo hash and paste it in. |
I wonder why the hash changes at all. Is it selecting dependencies based on python version?
There are many update.sh files but I did not find any that generated a vendorSha directly. They generate it with vgo2nix or yaml2nix.
Maybe we can try to build it in the update script and just put the hash in the file? |
@@ -20,7 +20,12 @@ let | |||
sha256 = "0302lcfjlw7nz18nf86z6swhhpp1qnpwcsm2fj4avl22rsv0h78j"; | |||
}; | |||
|
|||
cargoSha256 = "0d83dniijjq8rc4fcwj6ja5x4hxh187afnqfd8c9fzb8nx909a0v"; | |||
cargoSha256 = { |
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.
does cargo, depending on python version, fetch different dependencies?
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.
another possibility is that there's some reference to the python version, thus the vendor libs get a different hash
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.
The problem is that the Python version is used in the name
attribute of the Rust derivation. name
is used as part of the vendor directory and tarball. So, if the Python version is part of the name, the vendored tarball changes for every Python version.
(Cargo vendoring itself is reproducible modulo formatting changes in the metadata, which we normalize.)
A fix for this issue in the wasmer
Python derivation is in #110580.
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.
Going to close this in favor of daniels PR.
sandbox
innix.conf
on non-NixOS linux)