[Distutils] Major update to the metadata 2.0 draft PEPs

[Nick Coghlan]

On 1 Jan 2014 10:33, "PJ Eby" <pje at telecommunity.com> wrote:
>
> On Sat, Dec 21, 2013 at 9:46 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > I've just published the first draft of the metadata 2.0 spec that
> > moves all of the fields that aren't part of the core metadata or
> > potentially needed for dependency resolution out to a separate
> > "standard metadata extensions" PEP.
>
> Yay!
>
>
> > I think this makes PEP 426 itself substantially less overwhelming, and
> > also provides convenient names to refer to the various other subsets
> > of the metadata.
>
> Indeed!
>
>
> > Metadata 2.0: http://www.python.org/dev/peps/pep-0426/
> > Versioning: http://www.python.org/dev/peps/pep-0440/
> > Standard Extensions: http://www.python.org/dev/peps/pep-0459/
>
> I have only been skimming these so far, will comment more later, but I
> just want to mention that for standard extensions, what is the
> rationale for not defining e.g. commands as exports?  Or for that
> matter, defining hooks as exports?  Both commands and hooks have a
> payload that's the same as an export payload, i.e., a reference to an
> importable object.  I think it'd be good for them to be defined in
> terms of exports in order to reduce duplication of concepts and
> implementations, as well as providing a PEP-defined example of how to
> use export groups and export names effectively.

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.

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.

I'll take another look at using either parallel export groups, or else
allowing subdivision of export groups as a general feature.

> (Also, noting the
> mapping of current script export namespaces to the new metadata would
> be helpful for people implementing translation tools from setuptools
> metadata.)
>
> Last but not least, some of the export examples should use dotted
> post-module names (e.g. "some.module:RandomClass.a_class_method") to
> highlight that qualified names can be used there.  (Yes, the spec
> *says* qualified names, but it's the sort of thing that people
> overlook when the examples are all of unqualified simple names.)

Yeah, those are both good ideas.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140102/e03159c8/attachment.html>