On Thu, Apr 25, 2013 at 10:13 AM, Nick Coghlan <[email protected]> wrote:
> On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft <[email protected]> wrote: > > I like how Node.js packages handled this. The canonical form is {"name": > > "Donald Stufft", "email": "[email protected]", "url": > > "http://github.com/dstufft/"} (and what I think the internal > representation > > should be), but the tooling understands strings like "Donald Stufft > > <[email protected]> (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": "[email protected]", > "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": "[email protected]", > "url": "http://github.com/pypa"; > } > > or the distutils-sig+BitBucket variant of that: > > "contact": { > "name": "Python Packaging Authority/Distutils SIG", > "email": "[email protected]", > "url": "http://bitbucket.org/pypa"; > } > I guess we're still talking about Author field? I don't like the substitution of author with contact point. For the software catalog people need to know other packages made by the author, not the packages made by contact point. I also don't like the approach to "normalize metadata format" to the 5th form. What is the goal of the format? Why it is not recorded in PEP 426. If the goal is to make DB queries - then normalization is ok. If the goal is to make it readable then we need to make format easier to type. For DB catalog you will need to parse metadata and build indexes anyway. There is no need to embed a bomb to kill all rabbits to the meta format. For further work on this there needs to be a goal. If the goal is to help people to see who made what and encourage open source collaboration - that's one thing. If the goal is to make catalog a corporative asset out of packages and contact points, then it is another. I'd stick with Author and Contributor semantic for now and add all other stuff later. If further formalization is needed - there is a common notion of project People and Roles. IMO it is a better way to go.
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
