I'm reading up and done all those peps: 425 - compaibility tags 426 - metadata 2.0 427 - wheel binary format 1.0 440 - version identification and dependency specifications and trying to make sense from them. Well, they make sense to me, but to what do they apply? Example: I can now build, upload, and install a wheel for my distribution. I have imported setuptools in my setup.py script, and have run 'setup.py bdist_wheel'. The resulting file is named 'py2exe-0.9.0-py34-none-any.whl', which means: python tag 'py34', abi tag 'none', platform tag 'any' What this file really is: it is a library that only works on CPython 3.3 and 3.4, win32 and win_amd64. So I would have expected a filename like py2exe-0.9.0-py33.py34-none-win.whl or similar. Hoever, the only thing that I found which did change the filename is this section in the setup.cfg file (which is not appopriate for this distribution): [wheel] universal=1 So, the question is: Are the specifications in the PEPs above implemented somewhere or are they only 'specifications'? There are very detailed descriptions how to specify requirements in the metadata (in pep426), something like "supports_environments": ["python_version >= '3.3' and 'win' in sys_platform"] Where can I specify this? Does distutils support it? Do I have to manually edit some pdist.json file, or do I have to rename the created .whl? Thomas
On Thu, Jan 23, 2014 at 9:23 AM, Thomas Heller <theller@ctypes.org> wrote:
I'm reading up and done all those peps:
425 - compaibility tags 426 - metadata 2.0 427 - wheel binary format 1.0 440 - version identification and dependency specifications
and trying to make sense from them. Well, they make sense to me, but to what do they apply?
Example: I can now build, upload, and install a wheel for my distribution.
I have imported setuptools in my setup.py script, and have run 'setup.py bdist_wheel'.
The resulting file is named 'py2exe-0.9.0-py34-none-any.whl', which means:
python tag 'py34', abi tag 'none', platform tag 'any'
What this file really is: it is a library that only works on CPython 3.3 and 3.4, win32 and win_amd64. So I would have expected a filename like py2exe-0.9.0-py33.py34-none-win.whl or similar.
Hoever, the only thing that I found which did change the filename is this section in the setup.cfg file (which is not appopriate for this distribution):
[wheel] universal=1
So, the question is:
Are the specifications in the PEPs above implemented somewhere or are they only 'specifications'?
There are very detailed descriptions how to specify requirements in the metadata (in pep426), something like
"supports_environments": ["python_version >= '3.3' and 'win' in sys_platform"]
Where can I specify this? Does distutils support it? Do I have to manually edit some pdist.json file, or do I have to rename the created .whl?
Thomas
supports_environments is not implemented. Currently you should be able to just rename the created .whl to change the tags. In the future the wheel metadata will have to match the filename so you would need a 'retag' command or just better setup.cfg options. bdist_wheel supports this syntax for replacing the requirements metadata and including the full text of a license in the metadata, in setup.cfg. One drawback to this approach is that the wheel can have different dependencies than the non-wheel because vanilla setuptools doesn't generate the .dist-info style metadata. distutils sucks, but I haven't had the opportunity to write a replacement. [metadata] provides-extra = tool signatures faster-signatures requires-dist = argparse; python_version == '2.6' keyring; extra == 'signatures' dirspec; sys.platform != 'win32' and extra == 'signatures' ed25519ll; extra == 'faster-signatures' license-file = LICENSE.txt [wheel] # use py2.py3 tag for pure-python dist: universal=1
-------------------------------------------- On Thu, 23/1/14, Daniel Holth <dholth@gmail.com> wrote: supports_environments is not implemented. Perhaps not in pip and wheel, but there is support in distlib and distil. Specifically, distil should present a list of failing clauses in supports_environments for any distributions to be installed (including dependent ones). Of course, there's not much on PyPI one can test with, since that metadata is absent, so testing of this feature has been limited to local test data. Regards, Vinay Sajip
Are the specifications in the PEPs above implemented somewhere or are they only 'specifications'?
The Packaging User Guide is maintaining a summary of the relevant PEPs that gives a brief description of the "user impact" and "implementation" (i.e. whether projects are actually implementing any of this). https://python-packaging-user-guide.readthedocs.org/en/latest/peps.html For those working on the various projects, please help keep this up to date.
-------------------------------------------- On Thu, 23/1/14, Marcus Smith <qwcode@gmail.com> wrote:
The Packaging User Guide is maintaining a summary of the relevant PEPs that gives a brief description of the "user impact" and "implementation" (i.e. whether projects are actually implementing any of this). https://python-packaging-user-guide.readthedocs.org/en/latest/peps.html For those working on the various projects, please help keep this up to date.
A lot of this stuff is implemented in distlib and distil (distlib itself is just a library that provides the underpinnings, and some of the functionality required, such as actually installing stuff, is implemented in distil. I assume it's OK to add references to these? For example, distlib implements PEP 376, PEP 425, PEP 426, PEP 427, PEP 440, but only the last of these is mentioned on the PEP summaries page. Regards, Vinay Sajip
A lot of this stuff is implemented in distlib and distil (distlib itself is just a library that provides the underpinnings, and some of the functionality required, such as actually installing stuff, is implemented in distil. I assume it's OK to add references to these? For example, distlib implements PEP 376, PEP 425, PEP 426, PEP 427, PEP 440, but only the last of these is mentioned on the PEP summaries page.
certainly mention the distlib implementations, but also let's be clear if there is a pypa-recommend tool that is user-facing (like pip), that is using those parts of distlib. In most cases, that is not true currently. As for mentioning distil, I'm inclined to say no. Up to this point, you've presented it as a proof of concept. If you're wanting to mention "distil" as a real option for users, I'm concerned about fracturing the mind of users, but it's something to discuss I guess. Marcus
We need pip's build to become more like conda build. http://docs.continuum.io/conda/build.html A simple recipe, not necessarily part of the to-be-built package source, invokes build.sh to create a package. In that kind of system things like distil can be used at will. On Thu, Jan 23, 2014 at 2:12 PM, Marcus Smith <qwcode@gmail.com> wrote:
A lot of this stuff is implemented in distlib and distil (distlib itself is just a library that provides the underpinnings, and some of the functionality required, such as actually installing stuff, is implemented in distil. I assume it's OK to add references to these? For example, distlib implements PEP 376, PEP 425, PEP 426, PEP 427, PEP 440, but only the last of these is mentioned on the PEP summaries page.
certainly mention the distlib implementations, but also let's be clear if there is a pypa-recommend tool that is user-facing (like pip), that is using those parts of distlib. In most cases, that is not true currently.
As for mentioning distil, I'm inclined to say no. Up to this point, you've presented it as a proof of concept. If you're wanting to mention "distil" as a real option for users, I'm concerned about fracturing the mind of users, but it's something to discuss I guess.
Marcus
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
--------------------------------------------
certainly mention the distlib implementations, but also let's be clear if there is a pypa-recommend tool that is user-facing (like pip), that is using those parts of distlib. In most cases, that is not true currently. As for mentioning distil, I'm inclined to say no. Up to this point, you've presented it as a proof of concept.If you're wanting to mention "distil" as a real option for users, I'm concerned about fracturing the mind of users, but it's something to discuss I guess.
I hear what you're saying. I've positioned distil as a proof of concept purely because it hasn't had widespread use, but I certainly expect it to fulfil the same role as pip functionally (which it must do to be an effective test-bed for distlib). I understand that pip is the officially recommended tool, and don't want to muddy the waters, there being enough confusion about packaging in the wider community. It seems a shame that some of the improvements over pip won't be more widely available, but such is life. I have the use of them, so there's that :-) Regards, Vinay Sajip
On 24 January 2014 06:18, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
--------------------------------------------
certainly mention the distlib implementations, but also let's be clear if there is a pypa-recommend tool that is user-facing (like pip), that is using those parts of distlib. In most cases, that is not true currently. As for mentioning distil, I'm inclined to say no. Up to this point, you've presented it as a proof of concept.If you're wanting to mention "distil" as a real option for users, I'm concerned about fracturing the mind of users, but it's something to discuss I guess.
I hear what you're saying. I've positioned distil as a proof of concept purely because it hasn't had widespread use, but I certainly expect it to fulfil the same role as pip functionally (which it must do to be an effective test-bed for distlib). I understand that pip is the officially recommended tool, and don't want to muddy the waters, there being enough confusion about packaging in the wider community. It seems a shame that some of the improvements over pip won't be more widely available, but such is life. I have the use of them, so there's that :-)
The fact we're still working on PEP 426/440/459 so distlib and distil are chasing a moving target also makes it a little difficult to recommend them to end users at this point :) I actually expect that we'll see many of the internals of pip significantly refactored in the next 12 months or so - in addition to metadata 2.0, there's also The Update Framework support as a result of PEP 458, and once we get proper metadata publication on PyPI, then adopting a real dependency solver becomes a far more viable option than it is today (and both conda and Fedora's hawkey have tackled the problem of making a depsolver available to a Python based installation tool). pip, ultimately, is just a CLI - so long as that remains the case, then the internals can change radically (which is why I agree with the idea of it *not* having a public Python API, and instead leaving that to distlib). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Are the specifications in the PEPs above implemented somewhere or are they only 'specifications'?
The Packaging User Guide is maintaining a summary of the relevant PEPs that gives a brief description of the "user impact" and "implementation" (i.e. whether projects are actually implementing any of this). https://python-packaging-user-guide.readthedocs.org/en/latest/peps.html For those working on the various projects, please help keep this up to date.
Thanks for the pointer; bookmarked. Thomas
participants (5)
-
Daniel Holth -
Marcus Smith -
Nick Coghlan -
Thomas Heller -
Vinay Sajip