<p dir="ltr"><br>
On 1 Jan 2014 10:33, "PJ Eby" <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>
><br>
> On Sat, Dec 21, 2013 at 9:46 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> > I've just published the first draft of the metadata 2.0 spec that<br>
> > moves all of the fields that aren't part of the core metadata or<br>
> > potentially needed for dependency resolution out to a separate<br>
> > "standard metadata extensions" PEP.<br>
><br>
> Yay!<br>
><br>
><br>
> > I think this makes PEP 426 itself substantially less overwhelming, and<br>
> > also provides convenient names to refer to the various other subsets<br>
> > of the metadata.<br>
><br>
> Indeed!<br>
><br>
><br>
> > Metadata 2.0: <a href="http://www.python.org/dev/peps/pep-0426/">http://www.python.org/dev/peps/pep-0426/</a><br>
> > Versioning: <a href="http://www.python.org/dev/peps/pep-0440/">http://www.python.org/dev/peps/pep-0440/</a><br>
> > Standard Extensions: <a href="http://www.python.org/dev/peps/pep-0459/">http://www.python.org/dev/peps/pep-0459/</a><br>
><br>
> I have only been skimming these so far, will comment more later, but I<br>
> just want to mention that for standard extensions, what is the<br>
> rationale for not defining e.g. commands as exports?  Or for that<br>
> matter, defining hooks as exports?  Both commands and hooks have a<br>
> payload that's the same as an export payload, i.e., a reference to an<br>
> importable object.  I think it'd be good for them to be defined in<br>
> terms of exports in order to reduce duplication of concepts and<br>
> implementations, as well as providing a PEP-defined example of how to<br>
> use export groups and export names effectively. </p>
<p dir="ltr">I believe it was due to the extra layer of nesting they needed - using multiple parallel export groups with different final elements in their dotted names didn't feel right.</p>
<p dir="ltr">I guess that indicates a flaw in my initial design for the export definitions though - I agree it would be better if commands and hooks could be cleanly defined within the exports mechanism, rather than needing separate custom metadata extensions.</p>

<p dir="ltr">I'll take another look at using either parallel export groups, or else allowing subdivision of export groups as a general feature.</p>
<p dir="ltr">> (Also, noting the<br>
> mapping of current script export namespaces to the new metadata would<br>
> be helpful for people implementing translation tools from setuptools<br>
> metadata.)<br>
><br>
> Last but not least, some of the export examples should use dotted<br>
> post-module names (e.g. "some.module:RandomClass.a_class_method") to<br>
> highlight that qualified names can be used there.  (Yes, the spec<br>
> *says* qualified names, but it's the sort of thing that people<br>
> overlook when the examples are all of unqualified simple names.)</p>
<p dir="ltr">Yeah, those are both good ideas.</p>
<p dir="ltr">Cheers,<br>
Nick.<br>
</p>