I read through the latest versions of PEP 426 and 459 "Metadata 2.0 and extensions". Here are my comments.
The PEP suggests "setup.py dist_info" is a thing. Only "setup.py egg_info" works. It might make sense to refactor bdist_wheel to include a dist_info command, but if done badly it would break distributions that rely on the pluggable nature of .egg-info generation (most every part of the egg-info directory is written by a separate plugin). Why do we care about "Source labels MUST be unique within each project and MUST NOT match any defined version for the project."? I still think meta distributions are unnecessary and hard to understand. It's either a lot of trouble to try to discourage == dependencies while still allowing them sometimes, or an overcomplicated way to try to define requirements.txt 2.0 by allowing distributions that aren't exactly distributions. This sounds like a pain: " To avoid malicious hijacking of names, when interpreting metadata retrieved from a public index server, automated tools MUST NOT pay any attention to ``"provides"`` entries that do not correspond to a published distribution. " I'm not convinced that console scripts should not continue to be a specially named entry point / export rather than their own very similar thing. Overall both peps are quite good. We need to be able to put them to use to advance our goal of providing a transparently backwards-compatible Python packaging system. My peps repository on bitbucket has an updated json schema. _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
