<p dir="ltr"><br>
On 7 Apr 2014 23:15, "Daniel Holth" <<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>> wrote:<br>
><br>
> I read through the latest versions of PEP 426 and 459 "Metadata 2.0<br>
> and extensions". Here are my comments.<br>
><br>
> The PEP suggests "setup.py dist_info" is a thing. Only "setup.py<br>
> egg_info" works. It might make sense to refactor bdist_wheel to<br>
> include a dist_info command, but if done badly it would break<br>
> distributions that rely on the pluggable nature of .egg-info<br>
> generation (most every part of the egg-info directory is written by a<br>
> separate plugin).<br>
><br>
> Why do we care about "Source labels MUST be unique within each project<br>
> and MUST NOT match any defined version for the project."?</p>
<p dir="ltr">Hmm, I think that stems from an earlier versions that allowed requiring a source label. I'll double check.</p>
<p dir="ltr">> I still think meta distributions are unnecessary and hard to<br>
> understand. It's either a lot of trouble to try to discourage ==<br>
> dependencies while still allowing them sometimes, or an<br>
> overcomplicated way to try to define requirements.txt 2.0 by allowing<br>
> distributions that aren't exactly distributions.</p>
<p dir="ltr">PyObjC at least needs them, and things like OpenStack releases would need it (if published through PyPI).</p>
<p dir="ltr">Meta distribution is an essential part of encouraging decoupled component design, without increasing the complexity of consuming an overall "release".</p>
<p dir="ltr">><br>
> This sounds like a pain:<br>
> " To avoid malicious hijacking of names, when interpreting metadata retrieved<br>
>  from a public index server, automated tools MUST NOT pay any attention to<br>
>  ``"provides"`` entries that do not correspond to a published distribution. "</p>
<p dir="ltr">Yup. Necessary security feature for virtual provides in an untrusted environment, though.</p>
<p dir="ltr">><br>
> I'm not convinced that console scripts should not continue to be a<br>
> specially named entry point / export rather than their own very<br>
> similar thing.</p>
<p dir="ltr">This is mostly a usability issue, but also relates to the stricter requirements for installers.</p>
<p dir="ltr">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).</p>

<p dir="ltr">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.</p>

<p dir="ltr">><br>
> Overall both peps are quite good. We need to be able to put them to<br>
> use to advance our goal of providing a transparently<br>
> backwards-compatible Python packaging system.</p>
<p dir="ltr">Yeah, agreed - we're to the point now where finalising these PEPs is pretty high on the packaging agenda :)</p>
<p dir="ltr">> My peps repository on bitbucket has an updated json schema.</p>
<p dir="ltr">Sweet, thanks.</p>
<p dir="ltr">Cheers,<br>
Nick.<br></p>
<p dir="ltr">> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/distutils-sig">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</p>