PEP 621: Storing project metadata in pyproject.toml

[brettcannon]

@sersorrel

Under “Entry points”, “MUST not” should probably be “MUST NOT”; this is the only PEP that uses mixed capitalisation for that phrase (9 use all-caps, 44 use all-lowercase).

I can’t find such a case in the PEP.

@sersorrel

Does this depends on "readme.content-type" being included in dynamic ?

I don’t think so. I’ll update the PEP.

@sersorrel

Per the core metadata specification, “The only legal value [for charset ] is UTF-8.” Would it be worth removing this sentence and altering the following two to something like

This is covered by:

Tools MAY support alternative content-types which they can
transform to a content-type as supported by the `core metadata`_.

@bernatgabor

IMHO this is the biggest plus side, and the PEP should probably start with this.

Everyone is going to have a different opinion as to what the most important reason why this PEP should exist. I don’t think arguing about the order is worth it as long as the key motivations for everyone is somehow captured.

@bernatgabor

How would this work with setuptools attr: a.version ? IMHO would be nice to address that use case directly, for example, it should not be able to use it, this is a dynamic provide?

Yes, it would be a dynamic provide.

As for an example, it’s just specifying dynamic = ["version"] and however setuptools choose to let people specify that as the way to get the version so I’m not sure what the benefit would be in tossing in such an example.

@bernatgabor

I personally find the authors always a bit redundant. People tend to move on from projects, and new people step in to maintain it. As such the only up-to-date and useful list is of maintainers and as such would like to use maintainers instead of authors. I know authors is specified in core, but maybe we should take this opportunity to migrate to maintainers instead. The PyPi webpage thinks similarly setuptools · PyPI, as there’s a bigger focus on the page on maintainers than authors.

What the PEP is doing is what you’re suggesting, but standardizing on “author” instead of “maintainer”. I’ll call that out.

@bernatgabor

We should give some guidance on when the build backend may fill in things, and when not.

This is actually already a compromise of even allowing tools to do this as at least one person wants to just ditch all the trove classifiers we said to backfill. So we purposefully made it weak and underspecified as the assumption is the importance of the relevant classifiers will actually go away in the future.

@bernatgabor

Should we provide here a core set of URL keys recommended?

That’s a PyPI question for which I have a year-old issue about.

I’ve opened Clarify points brought up from public consultation by brettcannon · Pull Request #1465 · python/peps · GitHub to address the above and will merge it once one other co-author approves the PR.