[Distutils] Comments on PEP 426 and 459

Nick Coghlan ncoghlan at gmail.com
Tue Apr 8 05:59:43 CEST 2014

On 7 Apr 2014 23:15, "Daniel Holth" <dholth at gmail.com> wrote:
> 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."?

Hmm, I think that stems from an earlier versions that allowed requiring a
source label. I'll double check.

> 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.

PyObjC at least needs them, and things like OpenStack releases would need
it (if published through PyPI).

Meta distribution is an essential part of encouraging decoupled component
design, without increasing the complexity of consuming an overall "release".

> This sounds like a pain:
> " To avoid malicious hijacking of names, when interpreting metadata
>  from a public index server, automated tools MUST NOT pay any attention to
>  ``"provides"`` entries that do not correspond to a published
distribution. "

Yup. Necessary security feature for virtual provides in an untrusted
environment, though.

> 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.

This is mostly a usability issue, but also relates to the stricter
requirements for installers.

>From a usability perspective, I don't believe users should have to learn
about the arbitrary entry point support just to request install time script
generation. "scripts are just a specific kind of plugin" is a case of
confusing one possible implementation model with the semantic model uses
actually care about (where scripts and plugins are different things).

>From an installer perspective, the key difference is that the *installer
itself* is one of the intended consumers of the metadata, so if the
installer doesn't know how to handle script metadata, it should fail,
rather than silently doing the wrong thing. By contrast, most other entry
points are only relevant at *runtime* - the installer doesn't need to know
anything about them.

> 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.

Yeah, agreed - we're to the point now where finalising these PEPs is pretty
high on the packaging agenda :)

> My peps repository on bitbucket has an updated json schema.

Sweet, thanks.


> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140408/ff28c75e/attachment.html>

More information about the Distutils-SIG mailing list