Can we stack catkin venv workspaces ?

[asmodehn]

Just the question in the title : Can we stack (underlay / overlay) workspaces built with virtualenvs ?

One of the design decision I made early for catkin_pip was to not go the full virtualenv way, because :

• venvs are not made to stack up ( AFIK it was never considered in the design) on top of each other, from what I could gather,
• if we can go the python way, we want to be fully dynamic and then get rid of the whole catkin build layer anyway.

But with catkin_pip I am having issues with the recent pip version ( and the changing --target / --prefix options) when I build the "environment" by hand, so maybe the catkin + venv solution is better after all ?

So I am curious if there is any return on experience on your side on this topic, if there is any specific limitation on catkin_venv that catkin_pip could do differently, or if you think catkin_pip should adopt some similar design decision ?
Thanks for any light you can shed on this!

[paulbovbel]

catkin_virtualenv doesn't under/overlay the virtualenvs themselves - each package cmakelists generates a virtualenv containing all python requirements from the entire dependency tree.

So the current implementation is definitely bulky. I tried to avoid getting too deep into python internals, and used the considerably better tested dh_virtualenv as a base for making the package's virtualenv 'relocatable'.

The approach here is sort of orthogonal to catkin_pip - I was motivated primarily to enable pip dependency management (and as a bonus python3) for ros_buildfarm users, and make it transparent with standard tools like roslaunch/rosrun/rostest. I'd welcome any advice on how to do things cleaner - I have a fairly shallow grasp on python internals at this level.

[paulbovbel]

Going to close this as an issue, but I'd be happy to discuss any architecture ideas further