-
Notifications
You must be signed in to change notification settings - Fork 1
Fix consecutive build failures #7
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
Fix consecutive build failures #7
Conversation
f933f53 to
d43c53f
Compare
savannahostrowski
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
|
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( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, I think this got missed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh noooooo 🙈
Yeah, i forgot to cleanup the expression after the colon 😅
Should be fixed now 😊
eb52ccc to
1987a69
Compare
|
Thanks again for all the fixes! |
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 😊