With regards to authors / maintainers, I think that the major problem here is that the {Author,Maintainer}{,-Email} core metadata fields are not sufficiently expressive in their current form to handle what we’re trying to enable in PEP 621, but modifying the core metadata standards is an explicit non-goal of PEP 621.
As currently proposed, we’re changing the meaning of the Author field, effectively deprecating the Maintainer field, and I guess adding some semi-standardized way of specifying maintainer metadata. I think that repurposing an existing field for this purpose is going to be a problem in the long run, because you’ll get some packages where the Author and Maintainer fields mean one thing, and another where the Author and Maintainer fields means another thing, with nothing in the generated metadata to indicate what meaning they are using.
I suggest the following course of action:
- In this PEP, re-design the
author/maintainer/author-email/maintainer-emailspecification to hew more closely to the meaning of the fields as they currently exist¹, not as we would design them if we were designing it today. Seek provisional acceptance of the PEP in the same way that PEP 517 and PEP 518 are not yet finalized. - Write a new PEP to deprecate the
{Author,Maintainer}{,-Email}fields in favor of something designed from the beginning to avoid theauthor/maintainerconfusion (and possibly to give richer metadata about the authors). - Update the PEP 621 standard afterwards to include the new field, then finalize it.
The benefit to doing it this way is that the metadata remains clean and consistent, but this PEP isn’t blocked on fixing “how to specify authorship”. The downside to this is that we’d be including a field in PEP 621 that we fully intend to deprecate, which is not off to a great start.
¹I’m thinking we may want to put the authorship stuff into its own separate table, so that it doesn’t pollute the top-level [project] namespace with a bunch of cruft.