Fix consecutive build failures#7
Merged
savannahostrowski merged 1 commit intosavannahostrowski:mainfrom Jan 7, 2026
Merged
Conversation
f933f53 to
d43c53f
Compare
savannahostrowski
requested changes
Jan 7, 2026
Owner
savannahostrowski
left a comment
There was a problem hiding this comment.
Hey thanks for this! Happy to hear that you found the project useful 😄 !
Let's add a test for this too. I have CI that runs on all platforms so we can make sure this works on Windows as well (it should!).
d43c53f to
eb52ccc
Compare
Contributor
Author
|
I incorporated your suggestions and added the example from the description above as a test for the CI. 😁 |
every_python/main.py
Outdated
| if not result.success: | ||
| if not verbose: | ||
| progress.stop() | ||
| output.error( |
Owner
There was a problem hiding this comment.
Oops, I think this got missed
Contributor
Author
There was a problem hiding this comment.
Oh noooooo 🙈
Yeah, i forgot to cleanup the expression after the colon 😅
Should be fixed now 😊
eb52ccc to
1987a69
Compare
savannahostrowski
approved these changes
Jan 7, 2026
Owner
|
Thanks again for all the fixes! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation
TL;DR: There are some build artifacts that are left behind in the cpython repo that might mess up future builds.
For example:
Finding such cases can be difficult and from 3.12 till 3.15 I didn't find a single example but I also didn't try all commits. It seems that they are easier to trigger in earlier python versions <=3.4 but that's mostly a guess.
To clarify, it's not that every-python is unable to build 3.11.0 because it is, it just fails if 3.12.0 was build before.
My docker setup
For reproducability here is again my docker setup which failed before the change.I don't think for those two versions the x86 compatability mode is required but for completeness I want to state that I still used it:
docker build --platform linux/amd64 -t every-python .Implemented fix
The developer guide mentions to run
make cleanto resolve such problems.However at some point in time
make cleanalso ran the./configurescript which then would end up running twice in our setup, making the builds a lot slower. So took inspiration from the footnotes instead and choosegit clean -fdx.A screenshot of the repo after

every-python install v3.14.0wheremake cleanwill execute the configure script (I cannot explain why).Considerations
1) Compile Times
Since we are reseting the working dir before every build and therefore removing all object files I feared that consecutive builds might be a lot slower the object files can no longer be used as a cache. However, in my experience the configure step often dominated the build-time but this could also be because I'm running this on a beefy machine. Another point is that in general successive builds rarely were faster than the initial build pointing to the fact the the object-file cache doesn't work as well as I would have thought.
Anyway here are some compile times from my machine:
As you can see they are all about the same time.
2) Alternative solutions
Instead of running the command automatically we could suggest running the commands manually when the build fails, or add it as an optional flag.
I saw that in the
bisectcommand you usegit reset --hard && git clean -fdto clean up but this didn't work for some of my usecases because object files caused the issue which are ignored in .gitignore and therefore won't be cleaned with the clean command. This could be fixed by applyinggit clean -fdx.We could also spend more time figuring out why the build fails and develop a tailored solution that does the least required change, this however is less general and we might have to develop multiple such fixes for cleanups.
Thank you ✨
I spent way to much time trying to figure out to install every major release of python in a container (which is a niche project but still) before I discovered this tool and even with the time I spent triaging some bugs I'm still very happy I found it.
So finally with this fix and #6 I finally got all 3.x.0 releases (15 in total) installed in a single container 😊