inconsistency between PEP425 and wheel tags
For interpreter-specific tags PEP425 says: "The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead. PyPy should probably use its own versions here pp18, pp19." But in practice if you build with an alternate interpreter you just get the equivalent CPython version level, e.g. pycrypto-2.6.1-pp27-none-macosx_10_7_x86_64.whl for PyPy 2.2.1, when the PEP indicates it should be pp22. As an implementer, should I follow the spec or follow reality? If the latter, should PEP425 be amended? thanks! brian twitter.com/wickman
That should probably be considered a bug in bdist_wheel. I don't think there has been any movement on alternate implementations choosing what they want their PEP 425 tags to be. Are you implementing your own wheel generator? (neat) On Mon, Jan 20, 2014 at 12:28 AM, Brian Wickman <wickman@gmail.com> wrote:
For interpreter-specific tags PEP425 says:
"The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead. PyPy should probably use its own versions here pp18, pp19."
But in practice if you build with an alternate interpreter you just get the equivalent CPython version level, e.g. pycrypto-2.6.1-pp27-none-macosx_10_7_x86_64.whl for PyPy 2.2.1, when the PEP indicates it should be pp22.
As an implementer, should I follow the spec or follow reality? If the latter, should PEP425 be amended?
thanks! brian twitter.com/wickman
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
For now I'm just using bdist_wheel, but the question is more focused on the dependency resolution side where I need to select from a list of compatible wheels on a remote server. As it stands, I will be very unsuccessful if bdist_wheel produces pp27 tags and my downloader only looks for distributions tagged with pp22. :-) Happy to send out some pull requests. pip, wheel and distlib all get this wrong. AFAICT pip/wheel use the same pep425tags code. Does that have a shared home? ~brian On Tue, Jan 21, 2014 at 8:30 AM, Daniel Holth <dholth@gmail.com> wrote:
That should probably be considered a bug in bdist_wheel. I don't think there has been any movement on alternate implementations choosing what they want their PEP 425 tags to be.
Are you implementing your own wheel generator? (neat)
For interpreter-specific tags PEP425 says:
"The version is py_version_nodot. CPython gets away with no dot, but if one is needed the underscore _ is used instead. PyPy should probably use its own versions here pp18, pp19."
But in practice if you build with an alternate interpreter you just get
On Mon, Jan 20, 2014 at 12:28 AM, Brian Wickman <wickman@gmail.com> wrote: the
equivalent CPython version level, e.g. pycrypto-2.6.1-pp27-none-macosx_10_7_x86_64.whl for PyPy 2.2.1, when the PEP indicates it should be pp22.
As an implementer, should I follow the spec or follow reality? If the latter, should PEP425 be amended?
thanks! brian twitter.com/wickman
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On Tue, Jan 21, 2014 at 1:09 PM, Brian Wickman <wickman@gmail.com> wrote:
For now I'm just using bdist_wheel, but the question is more focused on the dependency resolution side where I need to select from a list of compatible wheels on a remote server. As it stands, I will be very unsuccessful if bdist_wheel produces pp27 tags and my downloader only looks for distributions tagged with pp22. :-)
Happy to send out some pull requests. pip, wheel and distlib all get this wrong. AFAICT pip/wheel use the same pep425tags code. Does that have a shared home?
~brian
Best to update the bdist_wheel one.
It's easy enough to change in distlib, but the use of "probably" in that PyPy-specific sentence in PEP 425 makes that statement as a whole less than definitive. Indeed, the clear specification is to use py_version_nodot, which on PyPy 1.9 at least gives me '27'. So, if we should be using the PyPy version number, I think PEP 425 should explicitly say something like On PyPy, use ''.join(sys.pypy_version_info[:2]) Or whichever PyPy-specific API is supposed to be used to get this information, if not the one I've suggested. Regards, Vinay Sajip -------------------------------------------- On Tue, 21/1/14, Brian Wickman <wickman@gmail.com> wrote: Subject: Re: [Distutils] inconsistency between PEP425 and wheel tags To: "Daniel Holth" <dholth@gmail.com> Cc: "DistUtils mailing list" <distutils-sig@python.org> Date: Tuesday, 21 January, 2014, 18:09 For now I'm just using bdist_wheel, but the question is more focused on the dependency resolution side where I need to select from a list of compatible wheels on a remote server. As it stands, I will be very unsuccessful if bdist_wheel produces pp27 tags and my downloader only looks for distributions tagged with pp22. :-) Happy to send out some pull requests. pip, wheel and distlib all get this wrong. AFAICT pip/wheel use the same pep425tags code. Does that have a shared home? ~brian On Tue, Jan 21, 2014 at 8:30 AM, Daniel Holth <dholth@gmail.com> wrote: That should probably be considered a bug in bdist_wheel. I don't think there has been any movement on alternate implementations choosing what they want their PEP 425 tags to be. Are you implementing your own wheel generator? (neat) On Mon, Jan 20, 2014 at 12:28 AM, Brian Wickman <wickman@gmail.com> wrote:
For interpreter-specific tags PEP425 says:
"The version is py_version_nodot. CPython gets away with no dot, but if one
is needed the underscore _ is used instead. PyPy should probably use its own
versions here pp18, pp19."
But in practice if you build with an alternate interpreter you just get the
equivalent CPython version level, e.g.
pycrypto-2.6.1-pp27-none-macosx_10_7_x86_64.whl for PyPy 2.2.1, when the PEP
indicates it should be pp22.
As an implementer, should I follow the spec or follow reality? If the
latter, should PEP425 be amended?
thanks!
brian
twitter.com/wickman
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
-----Inline Attachment Follows----- _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
The problem is that sys.implementation is relatively new, so there's no standard way to retrieve the implementation version prior to that addition to the language spec. I agree the PEP should be explicit that that tag needs to reflect the implementation's *ABI* stability, which may or may not align with the Python language version. We're going to need an update to the compatibility tagging spec to sort out the Linux distro compatibility issues anyway, so perhaps someone is prepared to tackle a revision to the compatibility tagging PEP? (The relevant repo for draft specs is https://bitbucket.org/pypa/pypi-metadata-formats - although it occurs to me that could use some tags to reflect published versions of accepted PEPs) Cheers, Nick.
participants (4)
-
Brian Wickman -
Daniel Holth -
Nick Coghlan -
Vinay Sajip