[FR] Remove License classifier warning

[gotmax23]

What's the problem this feature will solve?

setuptools v77.0.0 now prints a large deprecation warning when using License:: classifiers, even if the new license key in pyproject.toml is not used. This presents a problem for ansible. We can't adopt the new standard, as we don't store configuration in pyproject.toml (we use setup.cfg) and do not maintain a cumulative SPDX license expression that encompasses the additional GPL-compatible licenses present in the 80+ Ansible collections included in the ansible package, so we could not add an accurate license key (GPL-3.0-or-later by itself would be incomplete) even if we wanted to move our configuration. Printing this loud warning is unhelpful to us.

Describe the solution you'd like

Please consider removing this deprecation warning or maybe only raising it when configuration is sourced from pyproject.toml. It's not actionable and creates backwards compatibility issues.

Alternative Solutions

Removing the classifiers and not moving our config to pyproject.toml, but this would result in an overall loss in license metadata

Additional context

Thank you for working on setuptools!

Code of Conduct

• I agree to follow the PSF Code of Conduct

[abravalheri]

Hi @gotmax23 thank you very much for reaching out.

The thing is: this is not something that setuptools can do by itself.

License classifiers have been deprecated as a whole in the ecosystem, so in the future other tools may start to fail (e.g. PyPI or pip). It does not matter if the classifiers are coming from pyproject.toml, as it was deprecated fundamentally in the Core Metadata level (so everything that produces metadata, like setup.py or setup.cfg counts).

The deprecation of classifiers was introduced via PEP 639 (which was not championed by setuptools itself, we are merely following the standard).

The possible action point is to remove the classifier regardless if it comes from pyproject.toml, setup.cfg or setup.py.

---

I understand the frustration with license expressions, because setuptools itself also has a problem to calculate and maintain the a compound SPDX expression, considering all the bundled source code.

What I am personally considering to do is to make sure all license files are included in the distribution and then remove the deprecated classifiers without adding an SPDX expression.

I consider SPDX expressions nice to have, but at the end of the day they are (at best) proxies to the license files. License files are ultimately the source of truth, and what is usually required to be present in distributions.

I suppose it is also possible to include another file (e.g. LICENSE.info or NOTICE) that describes to the users where and how to find the precise license information for the different pieces of code (but in a way that is simply replicating in a more user-friendly way, the functionality of the License-file metadata -- associated with license_files in setup.cfg).

[gotmax23]

Thank you for your detailed response! I understand that license classifiers are deprecated in the ecosystem (although it seems unlikely that pip will refuse to install packages because of this), but perhaps setuptools raising deprecation warnings is not the right place to do that. PEP 639 says:

Otherwise [if the License-Expression field is not present], if this field contains a license classifier, tools MAY issue a warning informing users such classifiers are deprecated, and recommending License-Expression instead. For compatibility with existing publishing and installation processes, the presence of license classifiers SHOULD NOT raise an error unless License-Expression is also provided.

(https://peps.python.org/pep-0639/#deprecate-license-classifiers), so the PEP does not require that setuptools prints this warnings in this case.

In any case, I understand setuptools' desire to warn users about the deprecation. It's just the other maintainer of ansible's build scripts and I thought these warnings were a bit premature when License-Expression was only just introduced, and we were hesitant to remove metadata from our packaging, so I thought I'd reach out. It just seems to me that setuptools is deprecating very many things as of late.

[abravalheri]

Thank you very much @gotmax23 for the understanding.

(https://peps.python.org/pep-0639/#deprecate-license-classifiers), so the PEP does not require that setuptools prints this warnings in this case.

That is a good assessment. The PEP only says that setuptools may issue the warning.

I agree that it is unlikely pip will fail any time soon, but other tools like PyPI and twine have been paying special attention lately to correctness of metadata, so they may at some point stop accepting them.

In the case of setuptools, and why we addopted the "may": I think that it is better to raise awareness earlier rather than later, so that at least the users are informed of what is happening in the ecossytem.

We have not introduced any due date for the warning, so it is unlikely this is going to evolve into an exception any time soon. Before we completely remove the functionality, there will be a clear indication of when it is going to be removed.

In any case, I understand setuptools' desire to warn users about the deprecation. It's just the other maintainer of ansible's build scripts and I thought these warnings were a bit premature when License-Expression was only just introduced, and we were hesitant to remove metadata from our packaging, so I thought I'd reach out. It just seems to me that setuptools is deprecating very many things as of late.

Thank you for reaching out. I understand (we are going through some similar concerns right now particularly when it comes to license expressions). Maybe it is useful to share the concerns in https://discuss.python.org/c/packaging/14.

Regarding the frequency of the deprecations: some of them are organic and come from setuptools itself, others come from distutils, others are driven from the standardisation (like this one) and others are indirect unfolding from standardisation and responses to the changes in the ecosystem (e.g. deprecation of setup.py <command>).

The implementation of PEP 639 did introduce a lot of new deprecation warnings. However most of them were supposed to be hard exceptions in the text of the PEP, so we softened them up by introducing a deprecation period. (Not this deprecation in particular, this deprecation message was a "MAY", so not fundamentally required, but still a recommendation from the PEP).

In all fairness there are a lot of deprecation warnings that are actually old. What we are doing lately is 1. increase awareness (making them more verbose and prominent as suggested by the community) and 2. actually see through the deprecation periods and use the opportunity to simplify setuptools.

[abravalheri]

It has been suggested that we concentrate releases instead of following the release process described in https://setuptools.pypa.io/en/latest/development/releases.html.

I don't believe setuptools is in a position to do that.
If anything frequent releases and piecewise changes allow us to quickly fix things when something goes wrong.

We don't have enough dedicated people to afford moving to a fixed release calendar or accumulate changes over a long period of time.

Given that we use this "release frequent, release small" process, it does happen that deprecations are scattered in time.