On Apr 25, 2013, at 3:13 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> 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";
> }
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 | ncogh...@gmail.com | Brisbane, Australia
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
