-
Notifications
You must be signed in to change notification settings - Fork 511
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
platform-independent wheels #95
Comments
I concur, it would be great to have a platform-agnostic wheel as fallback when no platform-specific wheel is available for the platform. |
c.f. #43 |
The shared library is a binary compiled against certain arch and python version. there's no standard for shipping all of them in one wheel. That's why manylinux1 wheels exist. The project ships a whole bunch of them and then client (pip) selects which one to download and install. There's also So your request is either duplicate of #43 or I don't understand what you want. "generic" wheels are only shipped for projects with no binary dependencies, which is not pyyaml's case at all. |
I think what's being asked here is to produce generic wheels that don't use the LibYAML bindings and are therefore not platform-specific, as a fallback for when no more specific (eg. manylinux) wheels are available. This would be useful for packaging tools and distribution pipelines that only support wheels and can't build source distributions. |
Oh, so pure-python implementation, then? This would probably not make sense once manylinux1 wheels are out... |
I think it would still make sense because not every possible platform is covered even when manylinux wheels are available. So the generic wheels would act as a fallback. |
@webknjaz to elaborate on @rdb , if
Note that this is not a |
See some comments from #407 (comment) on this - while it is possible to build a pure-Python wheel with |
@bsolomon1124 it might work with all the pure python bits going in yaml-slow and have yaml depend on yaml-slow and add only the binary accelerated parts |
In pyodide you can |
I think most of us are still of the opinion that the presence of a pure-Python wheel under the I'd argue that splitting the package into separate Python + extension packages doesn't really solve the problem either; it's a matter of deps and discoverability, and a whole lot of new added complexity with two very tightly-coupled packages that arguably aren't very discoverable. Someone's getting hosed depending on what the dependent package's requirements specify, and whether The needs for pure-Python wheels in pyyaml have so far been niche enough that it seems like the problem needs to be solved elsewhere (private index, upstream fixes to those envs to allow install from an sdist, whatever)- the likelihood of breaking a huge swath of users is just too great to accommodate it on PyPI IMO. |
Recently twisted split their binary and pure python wheels and the feedback has been great so far |
Give it a few releases for breaking API/ABI changes on the native extensions and people that, eg, have the pure-Python part installed in an OS package and the native part installed with I'm not saying it's impossible, but the !/$ factor seems awfully low for the added complexity to build/test/release and the new potential runtime hassles it exposes (especially since there are no $ involved and all of us are working on this out of selfish desire to keep it working for our own needs ;) ). |
How about trialing the pattern in a wholly new project namespace like psycopg3 are doing? |
I use yaml for config files mostly. Not performance critical at all. Maybe json is a better choice. And json is in Python's standard library. Added bonus: good documentation. When I look at https://pyyaml.org/wiki/PyYAMLDocumentation occasionally, I'm bewildered. |
Related to #43 . A platform-independent pure-python wheel on pypi would be very useful for dependency resolution in linux projects.
PyYAML-?.??-py35-none-any.whl
Ultimately a manylinux wheel using libyaml would be ideal, but I understand the complications so this might be a fair compromise that's simple to implement.
The text was updated successfully, but these errors were encountered: