PEP 639 license metadata

[dgw]

We were thinking about this 3 years ago (as of tomorrow), in 2022:

Put a pin in PEP 639 (deprecates/replaces License and the license-related classifiers) for later.

I tried directly using the license = "EFLv2" format, but it's not supported yet. So we'll have to take another modernization pass at the metadata once the deprecations and their replacements actually take effect I guess. (Attempt to future-proof rejected!) This is also why I haven't removed the license classifiers.

Originally posted by @dgw in #2328 (comment)

PEP 639 is supported as of setuptools 77. The holdup now is that setuptools 75.4 removed support for Python 3.8, and I'm not aware of a workaround to use PEP 639 style before a supporting setuptools version.

I believe we can create a distribution with newer Python and the modern metadata style, then install it on py3.8 as long as pip is new enough. Plugin repos that don't run tests on py3.8 haven't run into this problem when updating their TOML. The problem here is that the test suite covers py3.8, but you can't build the package on py3.8. (I'll remark that sopel-irc/sopel-remind#15 currently fails to run its tests on py3.8 for the same reason; it can't install a new enough setuptools.)

There are upload-artifact/download-artifact workflows that could help with this, but then the "installed" sopel would no longer point to the source tree—and that doesn't sound great.

[Exirel]

The main issue with that is this message:

Please use a simple string containing a SPDX expression for project.license.
You can also use project.license-files. (Both options available on setuptools>=77.0.0).

By 2026-Feb-18, you need to update your project and remove deprecated calls
or your builds will no longer be supported.

See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.

When I use that to build the package. At some point, it'll be more and more difficult to even build the package for all these versions.

Python 3.8 needs to die.

[dgw]

Python 3.8 needs to die.

I mean, PyPA had the choice to not deprecate the old style so quickly after PEP 639 got implemented.

But yes, this is probably going to force us into dropping py3.8 for Sopel 8.1. This conflict of TOML style definitely falls under the version support policy stated for Sopel 8.0 (emphasis added):

We will continue to test against Python versions that reach end-of-life unless it becomes impractical to do so—in which case the next maintenance release of Sopel will officially drop support for the Python version(s) that can no longer be tested.

[Exirel]

I'm with PyPA on this one: Py3.8 EOL was 2024-10-07, and I think Python needs to evolve faster than a decade ago. All the good stuffs we have with packaging comes from people move away from older version of Python and older tooling.

So yeah, I think this might become one of the nail in the coffin for Py3.8 support. But heh, not today.

[dgw]

My point is only that having "people move away from […] older tooling" doesn't necessitate quickly deprecating and removing the older behaviors. It was a choice they made to have new versions of setuptools drop support for the older metadata style.

Perhaps I'm not following the metadata discussions closely enough to understand why this change has to be forced through in just a year or two, but ultimately that doesn't matter. We have to follow what they're doing and drop 3.8 a little earlier than hoped, or roll our own packaging tool that still supports pre-PEP639 license metadata. Guess which is easier? 😏

[Exirel]

Hm. It's past the due date. So, what do we do?

I'm in favor of dropping support for Python 3.8 in Sopel 8.1. Sure, it's not the best possible scenario, but the more time passes, the bigger the range of Python version we have to support - already 7 versions now, 8 by the end of the year with the release of Python 3.15 next October.