-
Notifications
You must be signed in to change notification settings - Fork 142
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
manylinux wheels don't pass auditwheel checks #155
Comments
I don't think this causes any actual problems, because we load all that code conditionally, so on any platform for which those binaries aren't compiled, the debugger still works as a pure Python library, although functionality may be reduced (e.g. no attach-to-PID). That said, we should try to fix the warning. This may be tricky because of how we are packaging our vendored copy of pydevd, though. |
It still applies to debugpy, so moving it to that repo. |
You may eventually need to fix it. I have read in a couple of places that the pypi folks were looking into running such checks to accept binary wheels. |
Note that this is not an issue for us. I came across this as I was running auditwheel on xeus-python, for the Jupyter debugger. |
Turns out that those warnings are not entirely spurious. We messed up the packaging such that all our stuff goes inside Furthermore, for the attach helper .so, we have some non-conformant dependencies (glibc version) - but the codepath that conditionally loads them only checks arch, not glibc. So it's possible to install that wheel in an environment that is supposed to be able to run manylinux1 binaries, and then have it fail at runtime (instead of fallback), if you use attach-to-PID. |
For platform-specific wheels, do not include attach-to-PID binaries for other platforms.
Environment data
Actual behavior
auditwheel fails on ptvsd's maynlinux wheels with
The text was updated successfully, but these errors were encountered: