updating setuptools with setup_requires causes build failure #2910
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2910
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We had one set of build failures: the LGTM static-analysis tool was using the lowest-acceptable version of all dependencies, including setuptools-11.3, which was too old to understand the
python_requires="<3.0"
clause that tells the world how ashamed we are to not support py3. We fixed this by adding both aninstall_requires=
andsetup_requires=
of>=28.8.0
.That caused a second set of build failures: when tox builds the sdist (before installing it into the new virtualenv), it does so with the sam e python that Tox itself uses (and using whatever version of setuptools was available to that python). Then it sees the
setup_requires=
in tahoe's setup.py and attempts to install it. Something doesn't get reloaded properly, because we wind up with an error that looks like:This seems related to https://github.com/tox-dev/tox/issues/334
We think we can fix this with a workaround described in that ticket: add
skipsdist = True
to thetox
section oftox.ini
. Ourtestenv
section already hasskip_install = True
because we (ab)use thedeps
feature to get editable installs (which are faster than building an sdist) with the "test" feature enabled (which gets uscoverage
andmock
and stuff).Since we're already not using the default install step, I don't think we need that sdist tarball either. I'm hoping that the
pip install
used for the deps will use the new virtualenv'spip
, which means it can upgrade setuptools (according to oursetup.py
'ssetup_requires=
) without triggering this bug.In 526b97c/trunk:
Yup, that seems to have fixed the problem.
I also had to change our Makefile to delegate tarball generation to tox, and add a tox environment to run
python setup.py sdist
as the Makefile used to do. This gives us a newer/updatable python/setuptools with which to run the sdist command. Without that change, themake tarballs
target was failing with the samecheck_specifier
exception from above.