0
$\begingroup$

Rosanswers logo

I am building ros2 foxy from source on a fully patched xubuntu 20.04.4 system on an x86 platform. It installs fine without critical errors. However, python nodes are installed in $packetname/bin instead of $packetname/lib/$packetname. I can not figure out why. This results in ros2 run and ros2 launch not finding any python based nodes.

This does happen for all packages that use setup.py entry_points to install nodes. For example package demos/demo_nodes_py installs talker and listener in the bin directory. I did check the setup.cfg and it is correct. If I change it to something invalid it raises an error. However, if it is valid, it seems to be ignored. When I install demo_nodes_py and check the result of setup() entry "install_scripts" is missing. If I specify it manually on console when running setup.py it is there and nodes are installed at the right location.

I can not deeply integrate ros2 in ubuntu and on the target system I do not have admin rights. I therefore can not use rosdep and build ros in a virtual environmennt in home. I can not attach files here so I posted a minimal install script here: install script.

I could reproduce this behavior on two ubuntu systems that were setup independently. The same script works fine on debian buster.

Some relevant software versions:

python: 3.8.10

pip: 22.0.3

setuptools: 60.9.3

wheel: 0.34.2

vcstool: 0.3.0

cmake: 3.16.3

colcon-core 0.7.1

colcon-python-setup-py 0.2.7


Originally posted by Manuel Martin on ROS Answers with karma: 21 on 2022-03-01

Post score: 2


Original comments

Comment by arahami on 2022-07-19:
hey, I have the same problem and couldn't find the solution yet. for me, it seems like colcon is totally broken and installs everything under /bin directory without any file extension (because it thinks it's handling a binary file?!). I created an empty test package with a default test_node (and nothing more). build the project. a file named test_node was created under bin directory. I also found some copies of the test_node.py under install and build. but ros2 run command doesn't seem to recognize any of them. setup.cfg is default ($base/lib/$package_name for both install and develop)

after sourcing setup.bash I can run the script under /bin directly in the terminal without using ros2 run command. (e.g: $ test_node)

Comment by arahami on 2022-07-19:
to make sure that ros2 (for any reason) isn't looking in the wrong directory for scripts I copied the file from /bin to other possible valid directories under build and install (inside and next to directories with package_name or dist-packages). this didn't work either (which I think indicates that ros2 run isn't even looking for python scripts! which is kind of logical considering that colcon didn't build the project for python in the first place!)

the worst part is that I don't from when and why exactly it started to behave this way because I was using --the symlink-install option for a couple of months and didn't care actually to build my projects.

so as a workaround I'll keep it symlinked for now. but of course, I know I messed up something. I just can't find it.

Comment by arahami on 2022-07-19:
also, I build projects in a docker container every day and it seems it's totally fine (as I expected). both my host and the docker container have ubuntu 20.04 os with ros2 foxy installed. for the host, I didn't use the Debian package and went with the download method. docker container is based on the same official osrf/ros container.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I found a workaround for my problem after some digging. It turns out, as far as I know, that building ROS2 in virtual environments with current versions of the packages (both virtualenv and python3 venv) is not possible. It triggers virtualenv detection in setuptools which then ignores entries in setup.cfg. There are related bugreports on ci github.

I follow their workaround and build ROS2 using the old virtualenv version 16.7.9. This works without issue.

Apart from these bugreports this behaviour does not seem to be documented anywhere. It would be great to add a warning to the respective install guides. If anyone knows of a better solution please let me know.


Originally posted by Manuel Martin with karma: 21 on 2022-08-01

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by arahami on 2022-08-05:
would you mark your question as answered for future use?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.