Sysop: | Amessyroom |
---|---|
Location: | Fayetteville, NC |
Users: | 43 |
Nodes: | 6 (0 / 6) |
Uptime: | 97:20:26 |
Calls: | 290 |
Files: | 904 |
Messages: | 76,468 |
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, prevent the module from being successfully imported if the
package being built, doesn't actually depend on it. Then we don't
actually need it to be installed, and all is well. This can be done at
the small cost of installing a fake "trove_classifiers" module and
mutating PYTHONPATH. It is inelegant and meh, but upstream has stated
that they will not implement a real fix.
Bug: https://github.com/pypa/setuptools/issues/4459
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
---
eclass/distutils-r1.eclass | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 7ab8dcae3265..9b9ba4b803ac 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1360,6 +1360,17 @@ distutils_pep517_install() {
EOF
)
fi
+ if [[ ${BDEPEND} != *dev-python/trove-classifiers* ]]; then
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 7ab8dcae3265..9b9ba4b803ac 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1360,6 +1360,17 @@ distutils_pep517_install() {
EOF
)
fi
+ if [[ ${BDEPEND} != *dev-python/trove-classifiers* ]]; then
It's not valid to access stacked variables like BDEPEND from ebuilds.
On 11/12/24 1:37 PM, Michał Górny wrote:
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass index 7ab8dcae3265..9b9ba4b803ac 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1360,6 +1360,17 @@ distutils_pep517_install() {
EOF
)
fi
+ if [[ ${BDEPEND} != *dev-python/trove-classifiers* ]]; then
It's not valid to access stacked variables like BDEPEND from ebuilds.
For what reason is it invalid? Is it about whether this will work
correctly or is there a policy reason banning it or... ?
e that this happens inside of a phase function, not at global scope.
So the value of the variable is determined by the contents of the
environment file, not from the incremental value when sourcing the
eclass at global scope.