Title: Maintainer information discarded when writing PKG-INFO
Type: behavior Stage: resolved
Components: Distutils Versions: Python 3.7, Python 3.6, Python 2.7
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: bbayles, dstufft, eric.araujo, ncoghlan, p-ganssle
Priority: normal Keywords: patch

Created on 2018-03-13 13:43 by p-ganssle, last changed 2018-05-15 19:20 by eric.araujo. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 6106 closed p-ganssle, 2018-03-13 15:27
Messages (12)
msg313747 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2018-03-13 13:43
This is basically the same as issue 962772, as there seems to have been a regression. The current version of distutils discards author= metadata if maintainer= is present, even though PEP 345 has added the Maintainer: and Maintainer-Email: metadata fields.

I think that the way forward is to have write_pkg_info generate separate Maintainer: and Maintainer-Email: fields.
msg313821 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2018-03-14 14:17
Thanks for the report and pull request. Do you happen to know if setuptools is also affected?

If yes, the problem will need to be reported & fixed there as well (otherwise the maintainer metadata will still be missing for many publishers), if no, then using it instead of plain distutils is a potential workaround in advance of the distutils fix rolling it.
msg313824 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2018-03-14 14:39
@ncoghlan Yes, setuptools is affected. I've reported it there as well:

I have patches for both distutils and setuptools prepared. The distutils patch is more controversial because this is apparently the documented behavior of PEP 314's Metadata Version 1.1, and distutils doesn't really have support for any of the *other* features of Version 1.2. You can see the concern (mostly on my side, frankly) on the PR, GH PR #6106.
msg313826 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2018-03-14 15:08
I think that the proposed change is a good thing in itself, but if distutils only supports metadata 1.1 then it should comply with that spec.

I expect most projects to be using setuptools these days (to support wheels for one thing), so keeping distutils unchanged and fixing setuptools may be the best path.
msg313827 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2018-03-14 15:16
One thing that's unclear to me is whether PKG-INFO metadata spec should be considered exhaustive or whether you can add additional fields and still be considered compliant with the spec. If the latter is true, I think there's some case to be made for populating Maintainer: and Maintainer-Email: even in a purely Metadata-Version: 1.1 PKG-INFO file.
msg313866 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2018-03-15 10:02
We allowed semi-standardised additional fields for an extended period with 1.2 (for Provides-Extra and Description-Content-Type), but folks mostly found it confusingly ambiguous, so Dustin created PEP 566 to define them officially as Metadata 1.3.

Given that, I agree with Éric that if distutils is still setting "Metadata-Version: 1.1", we should stick with the old PEP 314 behaviour and advise folks to migrate to setuptools if they'd prefer the updated behaviour.
msg314007 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2018-03-17 15:17
I've fixed this in setuptools ( PR here: ).

Should we leave this open to track distutils upgrading to support all of PEP 345, or close this with "distutils will never support > 1.1".  If the latter, maybe that should be explicitly documented somewhere?
msg314027 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2018-03-18 06:52
I'm going to abuse the "third party" resolution type a bit and mark this as closed (at least for now) on the basis of "use setuptools instead if you want the improved behaviour".

I've also opened to discuss coming up with a migration plan whereby *setuptools* eventually becomes the reference implementation of the distutils API, and we remove the CPython level implementation entirely.
msg314136 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2018-03-20 10:19
Donald made an interesting suggestion over on, which was to have distutils stop overwriting the Author metadata with the Maintainer metadata when both are specified and instead emit a warning about an unknown keyword argument.

I'm not sure we'd want to change the behaviour of mapping Maintainer -> Author (since it's a nice way to retain credit in the code, while changing the metadata on PyPI to reflect the current metadata), but I *do* think it would be reasonable to have distutils emit a warning that metadata version 1.1 can't represent the maintainer information properly, and folks should upgrade to using setuptools instead.

Éric, your thoughts?
msg314144 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2018-03-20 13:33
> Donald made an interesting suggestion over on, which was to have distutils stop overwriting the Author metadata with the Maintainer metadata when both are specified and instead emit a warning about an unknown keyword argument.

To be honest, that would not have helped in this situation. I didn't encounter this bug in distutils, I encountered it in setuptools, and I tried fixing it in both places because the comments on issue 962772 indicated that this *should* have been supported in distutils.

In the end I think it's fair to either freeze the distutils API and add a DeprecationWarning to indicate that this is no longer supported and everyone should move to setuptools or modernize it completely.
msg314706 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2018-03-30 19:10
+1 to have a warning from distutils for cases not handled by older Metadata PEP.
msg316704 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2018-05-15 19:20
See also #33388
Date User Action Args
2018-05-15 19:20:08eric.araujosetmessages: + msg316704
2018-03-30 19:10:54eric.araujosetmessages: + msg314706
2018-03-20 13:33:38p-gansslesetmessages: + msg314144
2018-03-20 10:19:51ncoghlansetmessages: + msg314136
2018-03-18 06:52:19ncoghlansetstatus: open -> closed
resolution: third party
messages: + msg314027

stage: patch review -> resolved
2018-03-17 15:17:38p-gansslesetmessages: + msg314007
2018-03-15 10:02:39ncoghlansetmessages: + msg313866
2018-03-14 15:16:06p-gansslesetmessages: + msg313827
2018-03-14 15:08:06eric.araujosetmessages: + msg313826
2018-03-14 14:39:49p-gansslesetmessages: + msg313824
2018-03-14 14:17:09ncoghlansetmessages: + msg313821
2018-03-13 15:27:02p-gansslesetkeywords: + patch
stage: patch review
pull_requests: + pull_request5869
2018-03-13 14:21:06ned.deilysetnosy: + ncoghlan
2018-03-13 13:49:17bbaylessetnosy: + bbayles
2018-03-13 13:43:49p-gansslecreate