bpo-33069: Add Maintainer and Maintainer-Email fields

[pganssle]

Per PEP 345, Author, Author-Email, Maintainer and
Maintainer-Email are all optional fields, this patch
implements reading and writing them properly into
PKG-INFO.

See bpo-33069

I think this should be backported to everything currently accepting bugfixes, i.e. 2.7, 3.6 and 3.7.

If this can't be done automatically I can work up a backport.

https://bugs.python.org/issue33069

[merwok]

Thanks for the ticket and clean PR (using subtest!).

The main question is: is it correct to write separate author and maintainer for all Metadata versions?
If the older metadata PEPs documented the behaviour of maintainer replacing author, there may be tools that rely on that.

[pganssle]

@merwok Good point.

Weirdly, distutils also generates metadata with version 1.0 or 1.1, not 1.2. I guess I assumed that distutils always generates metadata with the latest version, and that the older metadata versions were mostly for writing purposes.

Maintaining the ability to cleanly write all old metadata versions seems like a pretty significant maintenance burden, is that really the plan?

[pganssle]

Looking at the code more closely, it seems that distutils only supports Metadata Version 1.1. Would full support for version need to go into a feature release? Based on this issue, I was assuming that this was a regression. Is the fact that all versions of Python only support PEP 314 and not PEP 345 a bug, or is PEP 345 support a new feature?

[merwok]

The plan was to keep distutils frozen and implement new PEPs such as 345 in another stdlib module, but that didn’t happen because of poor code quality and fundamental scope issues (can’t have one tool that does four different things well). Now there is no plan and we keep distutils mostly frozen for fear of breaking tons of packages.

[pganssle]

So I should probably target this PR at setuptools instead?

[merwok]

The opinion of setuptools maintainers would definitely help. I don’t know if they have independent metadata code or use or extend distutils’ code for example.

[merwok]

@dstufft @jaraco It would help if you could advise on this ticket.

[jaraco]

My typical recommendation for changes in distutils is that we implement them in distutils (master) and then setuptools provides a backport of that functionality for older Pythons (or in a slightly different workflow, contribute to setuptools and shortly thereafter commit to CPython distutils).

I think that recommendation holds here as well.

There is some consideration that setuptools may actually adopt distutils but that work is stalled, so may not be relevant.

[pganssle]

@jaraco At the moment distutils is way behind setuptools in support for modern metadata formats, though. I have a patch for setuptools that fixes this same problem in setuptools (PR forthcoming as soon as I get IP release from my company), and what it does is bring setuptools into full compliance with metadata version 1.2.

What this patch on distutils does is add a Version 1.2 feature to a metadata file that is already version 1.1.

I'm fine with whatever the distutils maintainers want to do, but it does seem like it's actually quite a bit of work to get distutils into full compliance with version 1.2.

[merwok]

Given the last comment, should we close this PR?

[pganssle]

@merwok Yes, this is fixed in setuptools and so I think at this point now the goal for distutils should be fully deprecating it.