Dont use editable packages ?

[asmodehn]

editable packages create problems (compatibility with --prefix, dynamic discovery of their paths, etc.).

Although this feature might be interesting coming from python, it kind of break a few things in subtle ways when using catkin.

How about not using editable packages, and doing a REAL (pip) install into the devel workspace ?

This will solve a few tricky problems, and the drawbacks are that you need to build again before you can use the edited version... Maybe not such a problem if people are used to work with C++ and are using CMake anyway...

[asmodehn]

Or maybe it will encourage good habits (C++ flow with cmake in low level, highly dynamic flow without cmake, in venv high level, or other environment, connected with pyros), while not breaking the fact that python code runs in ROS workspaces.

[asmodehn]

Attempt : #90

[asmodehn]

Note this "regression" will not affect the main use of catkin_pip : take existing python packages and catkinize them without changing anything.
It will also entice people to move to a proper python workflow from a venv (using pyros_setup to import workspace not on system paths) if they desire the python dynamic development workflow.

[asmodehn]

Also it might be tricky but we would need to ensure python sources and targets are linked properly, to trigger rebuild when needed...

[asmodehn]

#90 kind of break the user expectation regarding the workflow (has to build after editing, and before testing...) We are able to avoid annoying pip bugs and simplify hacks between ROS and python, but the cost (loosing python dynamic advantage) might be too great...

• Best solution : change the way ROS setup his python environment to be compatible with python tools somehow...
• Second best solution : Hack around ROS/python differences and pip bugs, just like catkin_pip is doing now.

[asmodehn]

We will stick with editable packages for now. We should just focus on fixing pip bugs, but editable packages have the correct semantic for ROS devel space packages.