Skip to content
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

python3 -mvenv --upgrade-deps fails #218

Closed
dsp opened this issue Feb 21, 2024 · 2 comments
Closed

python3 -mvenv --upgrade-deps fails #218

dsp opened this issue Feb 21, 2024 · 2 comments

Comments

@dsp
Copy link

dsp commented Feb 21, 2024

When using a musl standalone build, python3 -m venv --upgrade-deps .venv fails due to "OSError: Dynamic loading not supported". This is one of the issues currently stopping rye from running on a musl only build. I tested this on both Ubuntu and Alpine.

This fails because venv will pull pip from ensurepip/_bundled and not the patched pip that is in site-packages. So the underlying issue is similar to #30.

I looked into Alpine's python and it's a dynamically linked python for which dlopen works.

@dsp dsp changed the title python3 -mvenv --upgrade-deps fails on Alpine python3 -mvenv --upgrade-deps fails Feb 21, 2024
@indygreg
Copy link
Collaborator

The statically linked musl builds are extremely limited in utility because of the lack of dynamic library loading support (https://gregoryszorc.com/docs/python-build-standalone/20240107/quirks.html#static-linking-of-musl-libc-prevents-extension-module-library-loading).

Long on the project backlog is #86, which likely entails building a dynamic musl libc and having separate CPython distributions that link against that. Those would likely be compatible with Alpine and PEP 656 platform tag for musl, which assumes existing of a dynamic musl library.

If PEP 656 had been around when I created this project, I may have just made musl libc dynamic by default.

Perhaps we should close this as a duplicate of #86?

@dsp dsp closed this as not planned Won't fix, can't repro, duplicate, stale Feb 24, 2024
@dsp
Copy link
Author

dsp commented Feb 24, 2024

The statically linked musl builds are extremely limited in utility because of the lack of dynamic library loading support (https://gregoryszorc.com/docs/python-build-standalone/20240107/quirks.html#static-linking-of-musl-libc-prevents-extension-module-library-loading).

Long on the project backlog is #86, which likely entails building a dynamic musl libc and having separate CPython distributions that link against that. Those would likely be compatible with Alpine and PEP 656 platform tag for musl, which assumes existing of a dynamic musl library.

If PEP 656 had been around when I created this project, I may have just made musl libc dynamic by default.

Perhaps we should close this as a duplicate of #86?

Sounds good. Thanks for the overview. I'll close it for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants