Wrong/misleading metadata if multiple maintainers are set

[stefan6419846]

At pypdf, we recently added a second maintainer:

[project]
name = "pypdf"
authors = [{ name = "Mathieu Fenniak", email = "[email protected]" }]
maintainers = [{ name = "stefan6419846" }, { name = "Martin Thoma", email = "[email protected]" }]

This leads to some strange/misleading metadata files:

Metadata-Version: 2.3
Name: pypdf
Version: 5.3.0
Summary: A pure-python PDF library capable of splitting, merging, cropping, and transforming PDF files
Author-email: Mathieu Fenniak <[email protected]>
Maintainer: stefan6419846
Maintainer-email: Martin Thoma <[email protected]>

I would have expected something like this:

Metadata-Version: 2.3
Name: pypdf
Version: 5.3.0
Summary: A pure-python PDF library capable of splitting, merging, cropping, and transforming PDF files
Author-email: Mathieu Fenniak <[email protected]>
Maintainer: stefan6419846, Martin Thoma
Maintainer-email: [email protected]

[takluyver]

I agree that's a bit confusing. It does seem to be what the spec for interpreting pyproject.toml metadata says:

If only name is provided, the value goes in Author or Maintainer as appropriate.
...
If both email and name are provided, the value goes in Author-email or Maintainer-email as appropriate, with the format {name} <{email}>.

Old versions of the metadata spec have Author-Email as a required field, and that has a more defined structure, so filling that is preferred if possible. I think the metadata (output) format is barely designed for multiple authors/maintainers, though, let alone mixing names with & without email addresses.

Maybe there's enough wiggle room there to do something like this: 🤔

Maintainer: stefan6419846, Martin Thoma
Maintainer-email: Martin Thoma <[email protected]>

[stefan6419846]

Thanks for the answer.

I think the metadata (output) format is barely designed for multiple authors/maintainers, though, let alone mixing names with & without email addresses.

Strangely enough, the pyproject.toml spec apparently considers this valid, thus indicating that there should at least be some defined mapping.

For me as the maintainer, I do not have a strong opinion. On the other hand, I know that some popular tools like pip-licenses (of which I am using a forked version myself to partially automate stuff and where I stumbled upon this initially) retrieve the maintainer from the Maintainer field and fall back to Maintainer-email otherwise. Thus, at least having all the defined maintainer names on the Maintainer field sounds like something which would at least cover/improve this use case.

[stefan6419846]

Apparently, this leads to some interesting side effects on PyPI as well, where my name is set as the maintainer, but linking to the e-mail address of Martin ...

[takluyver]

I've opened #721 for this. It should ensure that if anyone in the list doesn't provide an email address, all the names go in the Author/Maintainer metadata.

[stefan6419846]

Thanks. Having a quick look at the proposed PR, this looks fine for me.

[cdce8p]

I'm not sure it should be changed in flit. This does look like an existing issue with PyPI, see pypi/warehouse#9400 (comment).

Most are in agreement that PyPI should simply concatenate the metadata from email and non-email fields. I.e. for the original example it would be stefan6419846, Martin Thoma <[email protected]>.

Another argument against changing it in flit is that the current output matches that of other backends like hatch and setuptools. So it would be surprising and might even complicate the resolution of the PyPI issue if flit were to change it now.

[takluyver]

Thanks for the heads up. It doesn't exactly look like that PyPI issue is going to be resolved any time soon, though. I might post on discuss.python.org to see if we can get this resolved.

[takluyver]

Here's the thread for that discussion: https://discuss.python.org/t/combining-author-maintainer-names-emails-in-core-metadata/81011

[cdce8p]

Here's the thread for that discussion: https://discuss.python.org/t/combining-author-maintainer-names-emails-in-core-metadata/81011

Thanks for starting the discussing again! Let's see if it can reach a resolution this time.
Anyway, as the current behavior matches that of other build backends, it might be worth deferring #721 for now.

Would be awesome to have a new release with PEP 639 support soon.

[takluyver]

Yup, I agree, I'll keep this as is for now and make a new release. I think #721 is probably more or less what we want to do, but I'd rather not release that and then change the logic again if the discussion goes in a different direction.