What happens with this information? What tools currently read these fields (Author, Maintainer), what do they do with them?
They seem to be displayed on PyPI, for example python-dateutil:
There seems to be two kinds of maintainers (the second one relates to the PyPI users registered to the project I assume). Author is mentioned first (is it intentional or alphabetical order?).
What are the other current use cases? What tools read and use these fields?
This PEP in its current state seems to accept multiple authors, but the core metadata seems to be able to handle only one. Is that right?
In the mean time, I would like to reframe a bit my previous suggestion, not sure I had expressed my intent clearly. I will go off a bit in some “maybe in the future” at first, and then try to tie it back to the current PEP at the end of this message…
So for this PEP, as others have already expressed, no need to try and give a more concrete definition to these fields(Author, Maintainer). They are in the current core metadata specification so they need to be in PEP 621 one way or another.
For a potential future revision of core metadata I think I would advocate for more of a free style list of credits, in the same vein as the list of URLs. Each project would be free to choose labels (a role: Author, and Maintainer obviously which could be backwards-compatible, but also new ones Contributor, Designer, Patron), and a pair name / contact (email, URL, or physical address), for the people and organizations they want to credit.
I won’t go into how it would look like in the core metadata but in pyproject.toml, I propose it could look like the following:
credits = [
{role = "Author", name = "Me", contact="@"},
{role = "Author", contact = "https://localhost/"},
{role = "Maintainer", name = "Myself"},
{role = "Designer", name = "Them", contact = "That house in that town"},
{role = "Patron", name = "Us"},
{name = "I"}, # default role could be "Contributor"
]
A list of recommended roles (with semantic) could be curated by PyPA (PyPI) in the same vein as the trove classifiers or the work being done in warehouse to specify the labels for the project URLs.
Some here (@dustin, @brettcannon, maybe more) are in favor of framing this field as a list of contacts (not credits), I believe it could accommodate this as well (each project could chose what is more meaningful to them and their users).
I see that there might be some potential redundancy between this and the Project-URL fields though, that might need to be addressed.
From my point of view, if I were to want to contact someone about a project found on PyPI I believe I would look at the list of URLs first, and the list of authors, and maintainers second.
And to get back to the current PEP…
Today, with the current core metadata specification, by ignoring everything but the first Author and Maintainer, parsing such a table would be equivalent to:
credits = [
{role = "Author", name = "Me", contact="@"},
{role = "Maintainer", name = "Myself"},
]
And could map to this in the current core metadata:
Author-email: "Me" <@>
Maintainer: Myself
So it is quite a simple proposition in the end and very close to the current proposition. There would be no deprecation of Maintainer, no need to change the current core metadata, but still would offer enough room to extend later if we want to (we don’t have to) according to some of the wishes expressed in this discussion.
PEP 621, could potentially mention that other roles can be added past the first Author and Maintainer, but advise them against doing so as there is nothing to back them up yet (not in the package core metadata, or on PyPI at least).