-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
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
Python on Nix claims to be manylinux compatible #18484
Comments
That should be a matter of a simple patch to the interpreters adding that file. |
do you have a script I could run to test whether our Python is not anymore manylinux compatible? |
@FRidh just typed this one up - it can be pulled into a single command import _manylinux
assert not _manylinux.manylinux1_compatible |
I've pushed a fix to staging (63ec006). As soon as staging is merged into master the unstable channel will have the fix. |
Could someone explain why it's not manylinux compatible? It would be nice to be able to use manylinux1 wheels on Nix. Is it because of https://www.python.org/dev/peps/pep-0513/#the-manylinux1-policy or something deeper? |
Good question. I am not sure anymore the exact reason (we should have documented that) but if I am correct the main issue is that wheels can depend on certain libraries which we can provide, but which will be at a different location. When we build from source we hardcode the path to these shared libraries. In the case of a compiled wheel, we would have to patch after installation or pass |
nixos doesn't provide the requested libraries/symbol versions off-hand, also the more strict/save shared object location pinning requires exact library locations - so the only way to try and support manylinux1 would be a patched python that correctly sets up the linker, but at the same time that would weaken one of the benefits of nix/nixos - exact and consistent linkage |
Many manylinux1 binaries don't actually link to any external libraries. The declaration in Nix's |
Nix Python claims non-compatibility with manylinux binaries: NixOS/nixpkgs#21736
I think it makes little sense to disable manylinux1 compatibility in the name of trying to avoid inconsistent linking / external dependencies. The practical reality is that any package installed with pip -- whether manylinux1 or not -- could link to external libraries. If a user intends to use pip, they are already exiting the comfort of nix-managed packaging and should be treated as assuming those risks. Nonetheless, for users looking for a workaround, the compatibility flag can be overridden manually within a virtualenv (though perhaps not with python3.5's native
|
Is there a way of overriding this restriction without using a virtualenv? I'd like to just take responsibility for fixing up the linkage of a downloaded wheel during a regular nix build. EDIT: I figured this out for myself, sorry for the noise. I just copied the normal |
What do you guys think of actually adding I created a derivation which gathers together all the required libraries here. I would envision adding an option Even without further plumbing, you can use it like this:
If there's interest I can put together a PR. |
at first glance this looks interesting, i'd suggest to open a issue and/or pr with what you have (but i currently also dont use nix for personal reasons |
This should make packages in the manylinux1 wheel format work once they are installed. However, Nix's Python overrides pip's checks for whether the system supports manylinux1 using the _manylinux.manylinux1_compatible flag (more information about this available at NixOS/nixpkgs#18484). This override still needs to be removed before manylinux1 packages can be installed in the development environent.
Issue description
thanks to the rules in https://www.python.org/dev/peps/pep-0513/#platform-detection-for-installers
python on nix is considered to be manylinux compatible
in order to elevate the issue it is necessary to create a
_manylinux
python module that containsmanylinux1_compatible = False
The text was updated successfully, but these errors were encountered: