Best practices using ROS and Python package management
Hello everyone
The basic question is, what is the best way to deal with ROS and the underlying Python distribution and its package management. For my normal Python projects I use pyenv (for Python version management) and pipenv (for virtual environments and package management) and find this combination to work beautifully together. Is it recommended and possible to use pipenv together with ROS and what are pitfalls one would encounter and why is this not the documented standard? How do I make sure all Python code uses a specified virtual environment? What I've seen so far is that ROS simply uses the global system level Python distribution which let's me shiver when thinking on dependency management and conflicts for different projects I work on. I would love to hear some opinions on this issue and how to tackle it?
Best, Matt
I would also like to know an answer to this. 3 years of working professionally in ROS and the global python packages is the only solution that works for us. We just make sure no ROS env variables are set when we need to work on other virtualenvs for different projects.
I don't know about best practices, but use of
rospy(and many other ROS Python packages) in virtualenvs, pyenvs and similar environments (and Windows) should be possible with this.If that's not something you'd like to do (as it has "unofficial" in the name), you could take a look at catkin_virtualenv which has worked pretty well for me.
yes, as that is what upstream Debian and Python also do. As the release process / infrastructure of
ros_buildfarmis based on that, you get the same benefits, but also the same limitations.yes .. we all know it's far from ideal, but this sounds slightly judgemental. Perhaps not meant like it, but let's keep the discussion limited to the technical aspects.
You may also be interested to lookup some of the older posts by @asmodehn, both here on ROS Answers as well as on ROS Discourse. He has done quite some work on ROS in Python-only environments and has investigated some of the workflows that would make things a little more Pythonic.