mujoco: improve derivations

[tmplt]

The derivations for mujoco can be improved:

• [ ] Resolve revs of dependencies from the source At present, we have to trawl through the commit history between releases to check if any dependencies were updated, and copy their revisions. It is easy to miss a revision change, and as a result of being out-of-sync with upstream, we might get different numerical results. These are all inlined in CMake-failes. We can probably regex them out. With this fix we can just bump versions and update hash like a regular package.
• [ ] Properly package the Python package The Python package derivation is based on the pypi tarball which is built via mujoco's CI. We should nixify this. I've hit a bunch of Python bugs and testing fixes with the current packaging requires a lof of manual work because the patches are not compatible with current src.
• [ ] Use pinned glm rev To ensure numerical compat. See expression comment.
• [ ] Document this

Context via #317365.

---

Add a :+1: reaction to issues you find important.

[tmplt]

CC @GaetanLepage @samuela

[samuela]

Agreed on both points. I wonder if we could even do some kind of cmake-fu to evaluate the dependency versions... something like cmake metadata foo? (I know nothing about cmake)

[tmplt]

some kind of cmake-fu

$ cmake .. -LA | grep MUJOCO
MUJOCO_BUILD_EXAMPLES:BOOL=ON
MUJOCO_BUILD_MACOS_FRAMEWORKS:BOOL=OFF
MUJOCO_BUILD_SIMULATE:BOOL=ON
MUJOCO_BUILD_TESTS:BOOL=ON
MUJOCO_DEP_VERSION_Eigen3:STRING=454f89af9d6f3525b1df5f9ef9c86df58bf2d4d3
MUJOCO_DEP_VERSION_MarchingCubeCpp:STRING=5b79e5d6bded086a0abe276a4b5a69fc17ae9bf1
MUJOCO_DEP_VERSION_abseil:STRING=fb3621f4f897824c0dbe0615fa94543df6192f30
MUJOCO_DEP_VERSION_benchmark:STRING=e45585a4b8e75c28479fa4107182c28172799640
MUJOCO_DEP_VERSION_ccd:STRING=7931e764a19ef6b21b443376c699bbc9c6d4fba8
MUJOCO_DEP_VERSION_glfw3:STRING=7482de6071d21db77a7236155da44c172a7f6c9e
MUJOCO_DEP_VERSION_gtest:STRING=f8d7d77c06936315286eb55f8de22cd23c188571
MUJOCO_DEP_VERSION_lodepng:STRING=b4ed2cd7ecf61d29076169b49199371456d4f90b
MUJOCO_DEP_VERSION_qhull:STRING=0c8fc90d2037588024d9964515c1e684f6007ecc
MUJOCO_DEP_VERSION_sdflib:STRING=7c49cfba9bbec763b5d0f7b90b26555f3dde8088
MUJOCO_DEP_VERSION_tinyobjloader:STRING=1421a10d6ed9742f5b2c1766d22faa6cfbc56248
MUJOCO_DEP_VERSION_tinyxml2:STRING=9a89766acc42ddfa9e7133c7d81a5bda108a0ade
MUJOCO_ENABLE_AVX:BOOL=ON
MUJOCO_ENABLE_AVX_INTRINSICS:BOOL=ON
MUJOCO_ENABLE_RPATH:BOOL=ON
MUJOCO_EXTRAS_STATIC_GLFW:BOOL=ON
MUJOCO_HARDEN:BOOL=OFF
MUJOCO_SIMULATE_USE_SYSTEM_GLFW:BOOL=OFF
MUJOCO_SIMULATE_USE_SYSTEM_MUJOCO:BOOL=OFF
MUJOCO_TEST_PYTHON_UTIL:BOOL=ON

seems like the sanest approach. Good idea.

[tmplt]

I've added a glm task and a low-hanging Python-task. That should be everything: packaging MJX warrants its own issue, but perhaps we should make clear what isn't packaged? Would it make sense to have that in the package description?

And for the sake of control: is there significant reason to pin non-numerical packages also? Today that is cereal and spdlog.