[2298] Fix CI

[tjhunter]

Description

This PR should fix the CI issue. It makes several changes:

• update uv requirements (get fixes for resolution and workspace)
• introduce a sync-safe command that creates a venv in a more robust way. that should make sure that SCRATCH cache is touched and refreshed enough that it does not get cleaned
• fixes a number of issues when creating a new venv. these issues were hidden because of caching, they are now exposed every time by the CI.

Issue Number

Closes #2298

Checklist before asking for review

• I have performed a self-review of my code
• My changes comply with basic sanity checks:
  • I have fixed formatting issues with ./scripts/actions.sh lint
  • I have run unit tests with ./scripts/actions.sh unit-test
  • I have documented my code and I have updated the docstrings.
  • I have added unit tests, if relevant
• I have tried my changes with data and code:
  • I have run the integration tests with ./scripts/actions.sh integration-test
  • (bigger changes) I have run a full training and I have written in the comment the run_id(s): launch-slurm.py --time 60
  • (bigger changes and experiments) I have shared a hegdedoc in the github issue with all the configurations and runs for this experiments
• I have informed and aligned with people impacted by my change:
  • for config changes: the MatterMost channels and/or a design doc
  • for changes of dependencies: the MatterMost software development channel

[grassesi]

Tested the modified commands (sync-safe, lint) on Juptir: works fine. Note for people on Jupiter or juwels-booster who are using the uv package supplied by the module stack need to switch to standalone uv installation since the module stack only contains uv 0.7.4/0.8.17 . Alternatively we need to update the module stack.

[sophie-xhonneux]

This is a breaking change, let's wait until after June 10th when we present results.

[clessig]

This is a breaking change, let's wait until after June 10th when we present results.

What will be broken by this change?

[sophie-xhonneux]

From my understanding, it will force everyone to change their uv installation or be blocked and with insufficiently tested consequences. It is simply not worth doing this before June 10th

[grassesi]

If you installed uv using curl, it is as easy as runing uv self update. If you use the uv version on jupiter or juwels-booster that is supplied by the module stack it is just a matter of unloading the module (also disable the module in your bashrc) and reinstalling using curl.

What are the consequences you are afraid of? The only breaking change I can imagine is failing the upgrade or failing to build the environment after upgrade. Both can be tested in advance on different platforms if need be. The only possible change to the runtime environment of the weathergenerator itself is a potentially higher version of numcodes. (@tjhunter is this critical or not? might be easier to revert the version constraint to <0.16.0 if this alleviates concerns)