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.

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.

@ncoghlan Yes, setuptools is affected. I've reported it there as well: https://github.com/pypa/setuptools/issues/1288

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.

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.

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.

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.

I've fixed this in setuptools ( PR here: https://github.com/pypa/setuptools/pull/1294 ).

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?

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 https://github.com/pypa/packaging-problems/issues/127 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.

Donald made an interesting suggestion over on https://github.com/pypa/packaging-problems/issues/127#issuecomment-374401331, 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?

> Donald made an interesting suggestion over on https://github.com/pypa/packaging-problems/issues/127#issuecomment-374401331, 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.

+1 to have a warning from distutils for cases not handled by older Metadata PEP.

See also #33388