On Thu, Apr 25, 2013 at 10: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";
> }
>
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 - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
