[issue6992] Adding a Contributor field in PEP 314

[anatoly techtonik]

anatoly techtonik <techtonik at gmail.com> added the comment:

> The good pratice, if there are several authors, is to setup a
> mailing-list (and put its address as official contact address).

True. Some packages already do this.

> Otherwise collaboration gets inevitably messy, since authors can get
> contacted in private randomly.

People who use Python are usually smart enough to include all authors
in TO or CC field.

> I don't think we should multiply those fields in order to accomodate for
> subtle role differences. Also, I don't think PyPI is the place to record
> detailed attribution information. An ad-hoc CREDITS, ACKS file or
> similar is what you want IMO.

Well, I am writing a plugin and I my framework doesn't parse CREDITS,
ACKS or similar PEP, but it can extract package information to display
my name. I want my name to be displayed by this framework. It is
called Trac.

> What does changing the type of the "author" field make clearer exactly?
> It is a field for human beings to read, and a human being is perfectly
> able to parse "AP <ap at example.com>, Tarek <tarek at example.com>" without
> the help of a computer.

Type of `author` is not changed. It remains a single string that
doesn't include email. New field `authors` is introduced instead. It
can contain a single string with comma-separated authors. It is even
better than list.

> The metadata are completely messy. Users are already confused.

I think it should go into another `parent` ticket with a title like
"Perfection is achieved when there is nothing left to take away". =) I
think that we need to deprecate fields and leave links on their
meaning and how to translate them into other fields in documentation.
After three years everybody (well, at least the major part) will be
happy. Otherwise the frustration continue.

> Any change to the metadata fields will require a PEP 341 change, so
> everyone will be free to do a +1 or a -1.
>
> But saying that making the metadata evolve "is not the way we will make
> Python a reliable platform to use and develop for" is completely
> wrong imho.

+1

> Most of the meta data is parsed by humans, so I don't see any
> complication with adding multiple authors to the author field using
> standard email format: "Anatoli <email at here>, Tarek <email at here>".

Right, but then what author_email field is for? It looks almost
obvious that if author contain list of author names then author_email
should contain list of emails. Especially, when you add another author
to the package where author_email is already used. We should not
forget that developers who are overwhelmed with docs even without
distutils and try to keep rules short and simple.

> A metadata system, by definition, has to remain reasonably stable (or be
> version-numbered, such that old metadata can be recognized properly).
> You can certainly add fields, but replacing existing fields with others
> should be sufficiently motivated.

That's why it should be new `authors` field.

> In order to clear up the inconsistency with maintainer not
> being a possible meta-data field, I think "Maintainer" should
> be added to the meta-data. Dito for "Maintainer-EMail".
>
> Regarding making the meta-data fields multi-valued, you have
> to be aware that when parsing the meta-data using an rfc822
> style module, code assuming that only one Author field
> exists, will return (just) one of the available fields and
> it's not at all clear which.

This quote is totally confusing. Sounds WAY too complicated. If you're
going to switch to meta-discussions I may fall off at some point.

I suspect that there are some meta-internals of Distutils that I must
be aware of as a Python developer, but I just want to add myself to
setup.py along with other developer and learn my framework use this
info fully. Consider this a user-story.

>>> In order to clear up the inconsistency with maintainer
>>> not being a possible meta-data field, I think "Maintainer"
>>> should be added to the meta-data. Dito for "Maintainer-EMail".
>>
>> Do you remember what's the story behind those two fields ?
>
> I don't really remember, but suppose that the field was
> added for cases where a package is being abandoned by the
> original author and then maintained by someone new.

I thought that setup.py metadata format is extensible. Let's leave
`maintainers` extension to the tools that need it, i.e. PyPI. But IIRC
even PyPI doesn't use this field to grant access to package info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6992>
_______________________________________