distutils-r1.eclass now uses hatchling >=1.26 support for disabling
runtime use of trove_classifiers at all. It is still necessary as a
runtime dependency for the sake of people who install and run hatchling
via their user account, outside of ebuild packaging, but we no longer
need to guarantee that trove_classifiers is always ordered before
anything else during a world update.
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
In the previous commit, a change was patched into setuptools to enable
skipping pypi.org specific validations we do not want. Export the
environment variable which activates this, whenever the build backend is
setuptools.
Bug: https://github.com/pypa/setuptools/issues/4459
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
Trove classifiers, and their officialness, have no effect on a wheel
other than determining whether they are allowed to be uploaded to a
non-Gentoo website, and enabling the search index of that other site.
We don't need this, and we don't need to validate it. Setuptools will
disable validation if both of:
- network downloads failed
- cannot successfully import the `trove_classifiers` module
occurs. If trove-classifiers is installed by coincidence, this breaks
builds when it doesn't get updated on an extremely rapid basis and some
random package in dev-python/* uses a classifier that was made official
just the other day.
We could solve this another way, by making dev-python/setuptools
PDEPEND on trove-classifiers, and constantly bump the >= dependency. But
this is a pointless hassle. In fact, we're actually doing it, and it's
been a pointless hassle. We need to maintain up-to-the-minute minimum
bounds on the very latest version, and bump setuptools to a new -rX just
to update the minimum version of a package it doesn't even depend on. We
need to package new versions of trove-classifiers before *other* Gentoo
Devs outside of the python project, can successfully revbump their own
packages. We need to coordinate stabilization of trove-classifiers in
combination with those other packages. We force people to install a
pointless package. We overuse PDEPEND.
Instead, apply a *rejected* upstream patch to add an environment
variable that skips this specific validation code block entirely.
Upstream doesn't want to maintain code that contains branches, so we
will maintain it locally.
Since it is Gentoo-specific, the variable is also prefixed with GENTOO_
and is expected to be used solely inside of distribution packaging while
not affecting manual usage of setuptools outside of portage.
Bug: https://github.com/pypa/setuptools/issues/4459
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
Move the python3_13t target on the list before other CPython targets.
This means it's technically "less preferred", so e.g. *all phases
would rather be performed with regular CPython, which should generally
be more faster.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>