On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft <don...@stufft.io> wrote:
> I like how Node.js packages handled this. The canonical form is {"name":
> "Donald Stufft", "email": "don...@stufft.io", "url":
> "http://github.com/dstufft/"} (and what I think the internal representation
> should be), but the tooling understands strings like "Donald Stufft
> <don...@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": "don...@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-...@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@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   |   ncogh...@gmail.com   |   Brisbane, Australia
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to