Pyroma reports 'Your package does not have author data' when author is in fact specified in pyproject.toml

[bessman]

Per PEP621, author name and email should be specified in pyproject.toml as:

[project]
# ...
authors = [{name = "John Doe", email = "john@doe.com"}]

When this format is used, pyroma says 'Your package does not have author data.'

I suspect this is the reason:

1. If only name is provided, the value goes in Author/Maintainer as appropriate.
2. If only email is provided, the value goes in Author-email/Maintainer-email as appropriate.
3. If both email and name are provided, the value goes in Author-email/Maintainer-email as appropriate, with the format {name} <{email}> (with appropriate quoting, e.g. using email.headerregistry.Address).

I.e. if both name and email are both provided, the Author/Maintainer field is left unpopulated.

[CAM-Gerlach]

(FYI, the current canonical spec for the [project] table is the Declaring project metadata spec on the PyPA specs section of the PyPUG).

While the PEP doesn't specify, this is presumably to allow matching author names to emails and to be consistent with the array of tables structure in the source, as allowed by core metadata, despite the inconsistency with most existing backends.

In any case, a simple hueristic would be to check for </> (or a full regex, if really desired) in the Author-email/Maintainer-email field, and if so ignore the corresponding Author/Maintainer field left UNKNOWN. I cannot speak for @regebro , but I imagine he wouldn't mind a PR to fix this.

Presumably, the simplest way to do so would be to modify the Author test, to something like as follows:

class Author(FieldTest):
    weight = 100
    field = "author"

    def test(self, data):
        email = data.get("author_email")
        return True if "<" in email else super().test(data)

@regebro ?

[regebro]

IIRC reading metadata from pyproject.toml isn't supported yet.

[bessman]

The rest of the metadata gets read from the pyproject.toml without issue. I tested the change suggested by @CAM-Gerlach and it seems to work.

[regebro]

OK, great! I remember I was waiting for a release of setuptools, I didn't expect it would just start working by itself, but it seems it did, then.

i.e. if both name and email are both provided, the Author/Maintainer field is left unpopulated.

How amazingly annoying. OK, will fix when I get time.

[CAM-Gerlach]

IIRC reading metadata from pyproject.toml isn't supported yet.

The rest of the metadata gets read from the pyproject.toml without issue.

Actually, Pyroma doesn't read metadata from the pyproject.toml, but nor does it really need to following the suggested improvements @regebro implemented in #73 (though it would be more efficient if available, and the gaurentees in the PEP 621 spec allow you to rely on it if the key is not explicitly marked as dynamic). Rather, it relies on the project's chosen build backend to read the metadata from whatever format the user has specified it in (setup.py, setup.cfg, project table of pyproject.toml, tool table of pyproject.toml, flit.ini, etc), and then just reads the final static metadata (in RFC 2822 email header format) output by the backend (that would be included in a built wheel). Therefore, this will work regardless of the input format or backend.

How amazingly annoying. OK, will fix when I get time.

This was my take at first, but upon further though it actually makes sense, since otherwise if there were multiple authors, there would be no unambiguous way to match authors with email addresses. This is, IIRC, what several other existing backends already do and perfectly allowed by Core Metadata, so Pyroma would need to support it anyway.

In hindsight, a more sensible approach at the Core Metadata level would be to simply have one Authors field and list the authors and emails in the standard RFC 2822 format as now adopted, with some mechanism/heuristic for disambiguating a lone email or author name, but that ship has sailed.