-
-
Notifications
You must be signed in to change notification settings - Fork 231
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
Update Gitpod Docker image to Ubuntu Noble, uv package installation #3587
Conversation
use uv make variable for full path gitpod dockerfile do not use last stage
Clean up python.mak
I didn't see this one failing as it was only run on on PRs to main, I tested with a PR to main3 in my fork... |
Looks working. I made the Gitpod workflow test without and with uv. Without is about 50 secs, then I remove the venv and clear the cache (I hope I did correctly), and run again with uv installed, takes 7 secs (even to download the packages). It's about right. |
@nvuillam once this beta is released, we are quite due for a release, I'd try to use uv in the docker images. For having it tried out with it including pip and all inside the venv created, I'm quite confident that it will work, and will be faster for us. |
@echoix I see everything is green :) |
There isn't much more bash than there was before, but there is some make. My GNU make is quite fresh, I've played a lot with advanced makefiles this spring. And yes it's ok. |
The main thing to remember is that recipes (the contents indented in the rules), run each in a different shell, thus I'm surprised activating a venv in one line and using it in another actually worked before as intended. You would need to make it run in a single line (ie with semicolons, line continuations, etc) I tried to use bash-only if conditions, but I thought it was that that caused that it didn't work. Later on I understood it might have been something else, but the state here is better. I drafted the shell changes for the entrypoint.sh in another branch, as it wasn't needed here. |
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.
I trust ur jugement so let's go :)
I wanted to use gitpod again to build the docs. As before, running ./build.sh was broken because of a problematic python package.
It was impossible to update python version to 3.12 with Ubuntu Jammy (22.04). So I changed it to Ubuntu Noble (24.04). But that version enforced using venvs to not break system packages.
So instead of messing too much with pip environments, and having difficulty having them activated at the right time, I simply switched to uv, but keeping the pip code paths everywhere (and adding the
--seed
argument touv venv
in order to addpip
,setuptools
, andwheel
to the venv, not required, but makes it usable by pip afterwards, in case someone uses that naturally).Finally, in the docker image, I simply removed the last stage. It was simply adding another 30-40 seconds when wanting to load a new workspace (building and uploading the container on Gitpod's side). I don't consider it having a great value, as most probably users will have to have that image built before using it.
Proposed Changes
Readiness Checklist
Author/Contributor
Reviewing Maintainer
breaking
if this is a large fundamental changeautomation
,bug
,documentation
,enhancement
,infrastructure
, orperformance