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

[Donald Stufft]

On Apr 25, 2013, at 3:13 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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"
>    }


contact instead of author works for me. That's practically how it's implemented in distutils ATM anyways (Maintainer overrides author and gets sent _as_ the author).

> 
> 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.

I'm not sold on the pymeta.cfg file. Part of the purpose of defining the sdist format instead of the tool that creates the sdist format is that we allow any type of "input file" that someone wants to make a tool that does it. Further more package creation should ideally be moved out of the stdlib and I don't see much of a point to creating a PEP for a file that should never leave the developers computer.

> 
> 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


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130425/3fef77e8/attachment.pgp>