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-03-18 06:52 by ncoghlan. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 6106 open p-ganssle, 2018-03-13 15:27
Messages (8)
msg313747 - (view) Author: Paul Ganssle (p-ganssle) * 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) * 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) * 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) * 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.
Date User Action Args
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