-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reprotest-wheels
stalls installing python-dateutil
#350
Comments
The key part of the log seems to be:
|
What does this mean? (Using a diff just to highlight the parts that surprise me): ERROR: Could not find a version that satisfies the requirement python-dateutil==2.7.5 (from versions: 1.4, 1.4.1, 1.5, 2.1, 2.2, 2.3, 2.4.0, 2.4.1, 2.4.1.post1, 2.4.2, 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.6.0, 2.6.1, 2.7.0, 2.7.1, 2.7.2, 2.7.3, 2.7.4, 2.7.5, 2.8.0, 2.8.1, 2.8.2)
+ ERROR: ------------------------------------------------------------------------>2.7.5 (from versions: -keep scrolling-------------------------------------------------------------------------------------------------------------------------------->2.7.5<--------------------)
|
Nothing significant, it's just how pip expresses the error. Because 2.7.5 couldn't be installed, obviously none of the other versions on pypi work since we're pinned to 2.7.5. I did a bit of searching, I think bumping us up to 2.8.0 might fix it (https://dateutil.readthedocs.io/en/latest/changelog.html#id6 - addition of pyproject.toml) but also didn't finish looking into what that would take. |
I tried reproducing this locally and couldn't... 💭 not sure why. cd ~/src/securedrop-client
git checkout main
cp ~/src/securedrop-client /tmp/securedrop-clientlh0mh054
cd ~/src/securedrop-debian-packaging
git checkout release-securedrop-workstation-config # known to be failing in CI
pip3 download --no-binary :all: --require-hashes --dest /tmp/tmp8zgdeb0_ --requirement /tmp/securedrop-clientlh0mh054/requirements/requirements.txt
# exits successfully within a few minutes
|
Closes freedomofpress/securedrop-builder#350, in which reprotest-wheels is failing on securedrop-client's requirement of python-dateutil 2.7.5.
To unblock #355, #356, and #357 (with more to come), I started to update |
…lseye:2022_05_10) Now that we're assuming Python 3.9 under Debian bullseye, that's the environment we should use for testing wheel-level reproducibility. Closes #350.
In preparation for next week's retrospective on this problem in the Workstation release process, @creviera has asked me to look more deeply into why the |
My theory was that something in pip/setuptools/wheel/etc. was automatically upgraded and prevented the old version of the package from installing. But that doesn't really address why it started working on bullseye. I would also like to get rid of the "builder" image, it doesn't actually add any value here... |
I've been able to construct a minimal reproduction of this failure, revealing that:
We would have needed to wait for an upstream fix for python/importlib_metadata#392 to restore Python 3.7 compatibility, but we were able to sidestep that requirement by switching |
@cfm ooh, nice discoveries. Was the dependency not properly pinned? |
Good question. It's not obvious to me what to pin. I've just updated the reproduction to pin all of |
After today's retrospective, I'm working on a simplified reproduction, demonstrating the interactions of just |
Let's do some Socratic troubleshooting based on this even-narrower reproduction.... Why does Why does it fail to build from source? Because its backend dependency Why does Why does When was this change introduced in Can't we pin to
|
Specifically, installing
python-dateutil
forsecuredrop-client
in:https://github.com/freedomofpress/securedrop-debian-packaging/blob/b13e30d06d01a43b4909434f1cb38017b0dec951/scripts/build-sync-wheels#L75-L90
Evident in CI (e.g.) and reproducible by invoking manually:
Originally posted by @cfm in #349 (comment)
The text was updated successfully, but these errors were encountered: