Hi Guilhem,

I understand your motivation and I would say that currently, it makes sense to do something like this for the reasons you mentioned in #536 (reduction of build times, use of casadi). The packages you override have very low number of dependencies. Currently, I see the following unrelated dependencies:

• eigenpy: noetic/dynamic-graph-python, noetic/moveit-ros-planning-interface, noetic/tsid
• hpp-fcl: ø
• pinocchio: noetic/exotica-dynamics-solvers, noetic/exotica-examples, noetic/sot-core, noetic/tsid

All dependencies seem to be in noetic, which will be EOL soon. Therefore the risk of breaking other packages by using different version of overridden packages than what's in ROS is minimal (soon zero). If the number of dependencies grows in the future and the version dependencies will become a problem, we can revisit this change.

That being said, I'd propose a few changes:

1. You cannot override eigenpy the way you do it. It leads to eval errors, because in nixpkgs, the package is in python3Packages package set and not at the top level.
2. When overriding all repos, I think it's better to put the override to distros/distro-overlay.nix, which is used by all distros.
3. Add a comment before the override explaining why the override is needed.

Point 2. can look roughly like this:

diff --git a/distros/distro-overlay.nix b/distros/distro-overlay.nix
index 9d10193ac5..a65c2b29b0 100644
--- a/distros/distro-overlay.nix
+++ b/distros/distro-overlay.nix
@@ -72,6 +72,9 @@ let
   overrides = rosSelf: rosSuper: with rosSelf.lib; {
     # ROS package overrides/fixups
 
+    inherit (self.python3Packages) eigenpy;
+    inherit (self) hpp-fcl pinocchio;
+
     gazebo-ros = rosSuper.gazebo-ros.overrideAttrs ({ ... }:{
       setupHook = ./gazebo-ros-setup-hook.sh;
     });

The eigenpy override above is probably not sufficient. Building

nix build .#noetic.dynamic-graph-python

fails with:

┃        > -- eigenpy FOUND. eigenpy at /nix/store/mwa3pl41n7xr168hpqbxk5rbqi817yxp-python3.12-eigenpy-3.9.0/lib/libeigenpy.so
┃        > CMake Error at /nix/store/4m9iwwb202rii9h85jcc7dqh8p1pnqnb-python3.12-eigenpy-3.9.0-dev/lib/cmake/eigenpy/python.cmake:125 (message):
┃        >   /var/empty/bin/python3 is not a valid path to the Python executable

However, it seems that the same failure happens even before your changes.

Thanks a lot @wentasah for your review !

I'll try this later, but for now I can just quickly mention that I'm also the maintainer of TSID, dynamic-graph-things, and sot-things, so I'll have to take care of those anyways. I'm a bit late because they have way less users.