Making a wheel platform-specific?
Hello, I am trying to package a project which has the following features: - pure Python code (2- and 3-compatible) - no C extensions (therefore no CPython ABI issues) - but there's a .so file (or DLL) that's loaded at runtime using ctypes (FYI: https://github.com/numba/llvmlite) I would like to tell bdist_wheel to therefore tag the package as a Python-independent, platform-dependent binary package. There doesn't seem to be a way of doing so, or is there? Regards Antoine.
On 28 October 2014 12:57, Antoine Pitrou <solipsis@pitrou.net> wrote:
I would like to tell bdist_wheel to therefore tag the package as a Python-independent, platform-dependent binary package. There doesn't seem to be a way of doing so, or is there?
I don't believe there is at the moment. But the tags are *only* recorded in the filename, so it's perfectly OK to simply rename the wheel file manually after it's created. It would be nice to file a feature request for this on the wheel tracker (https://bitbucket.org/pypa/wheel) as well, if there's nothing there already, so we don't forget. Paul
On Tue, 28 Oct 2014 13:15:09 +0000 Paul Moore <p.f.moore@gmail.com> wrote:
On 28 October 2014 12:57, Antoine Pitrou <solipsis@pitrou.net> wrote:
I would like to tell bdist_wheel to therefore tag the package as a Python-independent, platform-dependent binary package. There doesn't seem to be a way of doing so, or is there?
I don't believe there is at the moment. But the tags are *only* recorded in the filename, so it's perfectly OK to simply rename the wheel file manually after it's created.
It would be nice to file a feature request for this on the wheel tracker (https://bitbucket.org/pypa/wheel) as well, if there's nothing there already, so we don't forget.
Ok, will do. I was assuming the compatibility tags would be recorded somewhere in the metadata. If I rename the file manually, is there an easy (CLI-based) way of uploading it to PyPI? Also, there's a remaining issue: how do I tell wheel that the package needs platlib rather than purelib? (may that question also apply to other bdist* flavours?) Regards Antoine.
2014-10-28 14:20 GMT+01:00 Antoine Pitrou <solipsis@pitrou.net>:
If I rename the file manually, is there an easy (CLI-based) way of uploading it to PyPI?
I had the same issue for a tool that collects wheels generated by various CI platforms to prepare a binary release. https://github.com/ogrisel/wheelhouse-uploader Here is the hack I did (a distutils command extension): https://github.com/ogrisel/wheelhouse-uploader/blob/master/wheelhouse_upload... -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel
On 28 October 2014 13:20, Antoine Pitrou <solipsis@pitrou.net> wrote:
If I rename the file manually, is there an easy (CLI-based) way of uploading it to PyPI?
I think twine can do that for you (and is generally recommended these days over setup.py upload, as it uses https).
Also, there's a remaining issue: how do I tell wheel that the package needs platlib rather than purelib? (may that question also apply to other bdist* flavours?)
You're right that's probably a more general question. For wheels, there's a "Root-Is-Purelib" entry in the WHEEL file in the metadata. That one would need manual hacking, unfortunately. Paul
On Tue, 28 Oct 2014 13:39:32 +0000 Paul Moore <p.f.moore@gmail.com> wrote:
On 28 October 2014 13:20, Antoine Pitrou <solipsis@pitrou.net> wrote:
If I rename the file manually, is there an easy (CLI-based) way of uploading it to PyPI?
I think twine can do that for you (and is generally recommended these days over setup.py upload, as it uses https).
setup.py upload also uses https these days, AFAIK. But I'll take a look at twine (*sigh*... another tool). Regards Antoine.
On Oct 28, 2014, at 9:43 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I think twine can do that for you (and is generally recommended these days over setup.py upload, as it uses https).
setup.py upload also uses https these days, AFAIK.
Paul forgot an important word there, *verified* HTTPS. It is true that recently Python switched the default from http:// to https:// however in any released version of Python it still does not *verify* that when uploading. I believe that PEP 476 will change that but it’s not in any released Python to my knowledge and even then it’s hard to tell people “Well setup.py upload is safe, in these particular scenarios” when it’s hard to declare exactly when those scenarios are (Python versions, but also some older versions thanks to downstream back porting patches etc). It doesn’t help either that the design of distutils doesn’t allow uploading an existing file so if you, for instance, want to upload a Python 2.6 specific Wheel then that won’t have PEP 476 and then something like twine is the only way forward. All in all it’s easier to just say “don’t use that, use this instead” than to explain when and why it’s ok to use that. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Tue, 28 Oct 2014 10:04:17 -0400 Donald Stufft <donald@stufft.io> wrote:
On Oct 28, 2014, at 9:43 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
I think twine can do that for you (and is generally recommended these days over setup.py upload, as it uses https).
setup.py upload also uses https these days, AFAIK.
Paul forgot an important word there, *verified* HTTPS.
Yes, you're right. Thanks for doing this. Regards Antoine.
On Tue, 28 Oct 2014 13:15:09 +0000 Paul Moore <p.f.moore@gmail.com> wrote:
On 28 October 2014 12:57, Antoine Pitrou <solipsis@pitrou.net> wrote:
I would like to tell bdist_wheel to therefore tag the package as a Python-independent, platform-dependent binary package. There doesn't seem to be a way of doing so, or is there?
I don't believe there is at the moment. But the tags are *only* recorded in the filename, so it's perfectly OK to simply rename the wheel file manually after it's created.
It would be nice to file a feature request for this on the wheel tracker (https://bitbucket.org/pypa/wheel) as well, if there's nothing there already, so we don't forget.
Ok, the issue already existed: https://bitbucket.org/pypa/wheel/issue/100/binary-wheels-for-different-pytho... Regards Antoine.
participants (4)
-
Antoine Pitrou -
Donald Stufft -
Olivier Grisel -
Paul Moore