Update Gitpod Docker image to Ubuntu Noble, uv package installation

[echoix]

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 to uv venv in order to add pip, setuptools, and wheel 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

1. …
2. …
3. …

Readiness Checklist

Author/Contributor

• [x] Add entry to the CHANGELOG listing the change and linking to the corresponding issue (if appropriate)
• [ ] If documentation is needed for this change, has that been included in this pull request

Reviewing Maintainer

• [ ] Label as breaking if this is a large fundamental change
• [ ] Label as either automation, bug, documentation, enhancement, infrastructure, or performance

[echoix]

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...

[echoix]

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.

[echoix]

@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.

[nvuillam]

@echoix I see everything is green :) My bash is quite poor so i'm not fully qualified to validate, but if you say it's ok I'll consider it ok then merge :)

[echoix]

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.

[echoix]

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.