Add scheduled workflow configuration to update pixi lockfile

[flferretti]

This PR adds a CI configuration to automatically update the pixi.lock with LFS support.

For the time being, since we have a PyPI dependecies, the workflow will take a bit more since it will try to install the update dependencies in the CI environment. We can re-add the --no-install option removed in ec00306 as soon as conda-forge/staged-recipes#27137 gets merged.

Note that it will be necessary to allow Github Actions to create/approve PRs from Settings ➡️ Actions ➡️ General (already checked with current settings):

Example PR: flferretti#14

Solves #199

---

📚 Documentation preview 📚: https://jaxsim--221.org.readthedocs.build//221/

[diegoferigo]

Looks good, thanks @flferretti! By chance, did you manage to test this action on your fork as discussed f2f? If not, no worries, we can merge and fix it upstream in a new PR.

[diegoferigo]

Any reason for including this change in this PR?

[flferretti]

jaxlib = "**cuda*" gives a TOML parse error. Moreover, it is not necessary to force the cuda version since the GPU version of jaxlib will be installed automatically if the __cuda metapackage is available.
I tested locally that with that change, the environment produces actually supports GPU:

$ pixi run -e gpu python                            
 WARN The feature 'style' is defined but not used in any environment
 WARN The feature 'testing' is defined but not used in any environment
 WARN The feature 'viz' is defined but not used in any environment
 WARN The feature 'all' is defined but not used in any environment
Python 3.12.4 | packaged by conda-forge | (main, Jun 17 2024, 10:23:07) [GCC 12.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import jax; jax.devices()
[cuda(id=0)]

[diegoferigo]

Mmh ok. However, sometimes upstream problems / conflicts may propagate downstream preventing the installation of the cuda version. It'd be safer to keep this specification IMO, otherwise the environment would silently build w/o GPU support. What about removing one of the leading *? Would it be a valid TOML entry?

[flferretti]

Yes, but it will not find any matching package:

$ pixi run -e gpu python
 WARN The feature 'style' is defined but not used in any envi
ronment
 WARN The feature 'testing' is defined but not used in any en
vironment
 WARN The feature 'viz' is defined but not used in any enviro
nment
 WARN The feature 'all' is defined but not used in any enviro
nment
  × failed to solve the conda requirements of 'gpugroup'
  │ 'linux-64'
  ╰─▶ Cannot solve the request because of: No candidates
      were found for jaxlib cuda.*.

[diegoferigo]

I see, cc @traversaro

[diegoferigo]

As in: https://github.com/Tass0sm/corallab-lib/blob/7c4c201528d2f758c560cb67efdcf2271afd8228/pyproject.toml#L30

[flferretti]

I guess we actually need CUDA 12 for the newest version of jaxlib, but apart from that, the modified pyproject works correctly even without forcing the GPU version of jaxlib

[diegoferigo]

Last attempt :) If this does not work, no problem. Possible future errors in GPU resolution will be temporary.

diff --git a/pyproject.toml b/pyproject.toml
index 0699a2c..5298be2 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -206,10 +206,14 @@ pytest-icdiff = "*"
 robot_descriptions = "*"
 
 [tool.pixi.feature.gpu]
-dependencies = { cuda-version = "12.*", cuda-cupti = "*" }
 platforms = ["linux-64"]
 system-requirements = { cuda = "12.1" }
 
+[tool.pixi.feature.gpu.dependencies]
+cuda-version = "12.*"
+cuda-cupti = "*"
+jaxlib = { version = "*", build = "*cuda*" }
+
 [tool.pixi.pypi-dependencies]
 jaxsim = { path = "./", editable = true }

[flferretti]

This works, thanks a lot! Addressed in aa532e2

[traversaro]

I'm not sure if pixi in this case expects cuda to be installed system-wide or it installs it from conda-forge.

As for conda, the driver part of cuda should be installed system-wide (and have a newer version w.r.t. to the cuda version used), while the cuda libraries are installed by conda-forge.

[flferretti]

Looks good, thanks @flferretti! By chance, did you manage to test this action on your fork as discussed f2f? If not, no worries, we can merge and fix it upstream in a new PR.

Thanks @diegoferigo! Please check flferretti#14

[diegoferigo]

Looks good, thanks @flferretti! By chance, did you manage to test this action on your fork as discussed f2f? If not, no worries, we can merge and fix it upstream in a new PR.

Thanks @diegoferigo! Please check flferretti#12

Awesome!

[diegoferigo]

No need to say, @flferretti trigger a pixi.lock update after merging :) Let's try to remember to do it before tagging releases (please remind me 😄).

[flferretti]

No need to say, @flferretti trigger a pixi.lock update after merging :) Let's try to remember to do it before tagging releases (please remind me 😄).

We could set that in workflow_dispatches