Update python and license classifiers when publishing.

[mforbes]

Problem

After switching from Poetry and uploading a packaged to PyPI I found that the python and license classifiers were not generated, breaking badges etc. The requires-python and license metadata fields in pyproject.toml contain enough information to add the appropriate Python and Licence classifiers, respecting the principles of DRY.

Describe the solution you'd like

pdm publish to fill in missing Python and License classifiers upon submission, as Poetry does. At the very least, a clear note in the documentation that PDM does not do this.

References

• https://github.com/pdm-project/pdm/issues/748#issuecomment-1004012528: Perhaps this feature existed in the past and was removed here? My understanding is that this is due to the following clause in PEP-621 Allow tools to add/extend data:

  In an earlier version of this PEP, tools were allowed to extend data for fields. For instance, build back-ends could take the version number and add a local version for when they built the wheel. Tools could also add more trove classifiers for things like the license or supported Python versions.

  In the end, though, it was thought better to start out stricter and contemplate loosening how static the data could be considered based on real-world usage.

  Can this feature be retained and made optional so that users have the option of doing this, thereby providing examples of "real-world usage"? (I have no idea what the PEP reviewers have in mind here: if the tools prohibit this behaviour, how will real-world usage reflect desire? Is Poetry going to be the only tool defining real-world usage?)

P.S. I am not clear on the relationship between the builtin pdm publish command and the pdm-publish plugin. Should I be submitting this to the latter instead?

[frostming]

• Incompatibility with PEP 621 #748 (comment): Perhaps this feature existed in the past and was removed here? It is not clear to me what the issue was, or why this feature cannot be included upon publish

We just decide not to do that to break PEP 621: all dynamic fields must appear in dynamic and can't have static values at the same time. PDM is trying to be a standard build frontend that doesn't do any special on its side, so that redistributors can build from the source with another standard-compliant tool such as build. Poetry doesn't support PEP 621 at all, so don't compare PDM to it thanks.

P.S. I am not clear on the relationship between the builtin pdm publish command and the pdm-publish plugin. Should I be submitting this to the latter instead?

pdm publish is an official replacement, and the plugin should be deprecated.

[mforbes]

Then this request becomes a request to update the documentation so it is clear what PDM does or does not do.

Specifically.

1. To https://pdm.fming.dev/latest/pyproject/pep621/, add a Python Version and License section:

   Python Version

   The required version of python is specified as the string requires-python:

   requires-python = ">=3.9"
   classifiers = [
     "Programming Language :: Python :: 3",
     "Programming Language :: Python :: 3.9",
     "Programming Language :: Python :: 3.10",
     "Programming Language :: Python :: 3.11",
     ...
   ]

   Note: As per PEP 621, PDM is not permitted to dynamically update the classifiers section like some other non-compliant tools. Thus, you should also include the appropriate trove classifiers as shown above if you plan on publishing your package on PyPI.

   License

   The license is specified as the string license:

   license = {text = "BSD-2-Clause"}
   classifiers = [
     "License :: OSI Approved :: BSD License",
     ...
   ]

   Note: As per PEP 621, PDM is not permitted to dynamically update the classifiers section like some other non-compliant tools. Thus, you should also include the appropriate trove classifiers as shown above if you plan on publishing your package on PyPI.

2. When when running pdm init for generating a library, the appropriate trove classifiers should be included in pyproject.toml, perhaps with a comment telling the user that these must be manually updated if requires-python or license change.

3. Somewhere, there should probably be a guide for migrating from Poetry to PDM. I will add a note about this to #520, but it would be really nice if there was a proper discussion and a checklist.

If this is copacetic, I can submit a PR for 1. (not sure how hard 2. would be).

The comparisons with Poetry come because I am migrating from Poetry after being dissatisfied with the trouble it caused. I appreciate trying to be standard compliant, but it is very frustrating when, after spending quite a bit of effort to migrate, I run into more issues and there is no documentation explaining why my expectations are not being met. I suspect a large number of users will try to make a similar switch based on recent discussions (see 1 and 2), but if they run into the same problems I am running into, they will probably leave.

I appreciate the efforts to make a standards compliant tool, and really want to support the adoption of the one -- and preferably only one -- obvious way of doing it: I am hoping that PDM will become this tool, but it won't if it is hard to use.

[frostming]

@mforbes thanks for the suggestion, would you like to send a PR?

[vvanglro]

same issue.