[Distutils] Simplify 426: Deprecate Author-email and Maintainer-email

Nick Coghlan ncoghlan at gmail.com
Thu Apr 25 09:13:35 CEST 2013


On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft <donald at stufft.io> wrote:
> I like how Node.js packages handled this. The canonical form is {"name":
> "Donald Stufft", "email": "donald at stufft.io", "url":
> "http://github.com/dstufft/"} (and what I think the internal representation
> should be), but the tooling understands strings like "Donald Stufft
> <donald at stufft.io> (http://github.com/dstufft/)". And both the email and url
> data is optional.

How about the following as the canonical PEP 426 representation:

    "contact": {
        "name": "Donald Stufft",
        "email": "donald at stufft.io",
        "url": "http://github.com/dstufft/"
    }
    "contributors": [<list of individual contact entries>]

The point of the neutral "contact" entry is that it may be a larger entity like:

    "contact": {
        "name": "Python Packaging Authority",
        "email": "pypa-dev at googlegroups.com",
        "url": "http://github.com/pypa"
    }

or the distutils-sig+BitBucket variant of that:

   "contact": {
        "name": "Python Packaging Authority/Distutils SIG",
        "email": "distutils-sig at python.org",
        "url": "http://bitbucket.org/pypa"
    }

As I work on the PEP 426 conversion to JSON as the on-disk format, I'm
also becoming convinced that we'll want at least a draft of the
replacement for PEP 390 (static input metadata) before I accept the
metadata 2.0 spec.

The key difference relative to PEP 390 is that the new PEP (for a
"pymeta.cfg" file) will be solely intended as an *input* format to a
build tool that populates pymeta.json when creating an sdist or wheel
file, whereas PEP 390 wanted to use the same format both for the
human-friendly input *and* as the machine readable interchange format.
Working on the PEP 426 conversion has confirmed my opinion that
splitting them is the right way to go, and also that a multi-file
input format is likely a better option than trying to cram everything
into one file.

Those two PEPs will then define "this is where we want to get to"
based on everything we've learned from the status quo and from looking
at other languages. Then the real work begins of figuring out how the
hell we can actually get there in a reasonable amount of time :)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Distutils-SIG mailing list