Alpha8 hard coded paths

Next Generation ROS
1

As a continuation of
https://groups.google.com/forum/#!topic/ros-sig-ng-ros/398dPsbcSQY and
https://groups.google.com/forum/#!topic/ros-sig-ng-ros/vYENgkU01o4

I noticed a lot of unexpected hard coded paths in the binary releases of alpha 8. Note that I only checked Windows and Linux.

In the Linux installation directions at https://github.com/ros2/ros2/wiki/Linux-Install-Binary, it mentions putting the release in “~/ros2_install” and yet I see a lot of references to /home/rosbuild/ci_scripts/ws. In the Windows installation instructions at https://github.com/ros2/ros2/wiki/Windows-Install-Binary, it mentions putting the release in “C:\dev\ros” and yet I see a lot of references to “C:\J\workspace\packaging_windows\ws”.

The biggest issues that I noticed so far is the inability to link to the TF2 library on Windows and the inability to run ament directly on Linux. Can we get the binary releases to match the installation instructions?

Specific details are below:
in ros2-windows\share\ament_index\resource_index\parent_prefix_path
Everything is prepended with C:\J\workspace\packaging_windows\ws\install

py3.5.egg-info
ros2-windows\Lib\site-packages*-0.0.0-py3.5.egg-info\SOURCES.txt
or
ros2-linux\lib\python3.5\site-packages*-0.0.0-py3.5.egg-info\SOURCES.tx

ros2-windows\CMake\console_bridge-config.cmake
Line 6: set(console_bridge_INCLUDE_DIRS “C:/J/workspace/packaging_windows/ws/install/include”)
Line 11: PATHS “C:/J/workspace/packaging_windows/ws/install/lib”

all the scripts in the ros-linux/bin/python and ros-linux/bin/launch have the #!/home/rosbuild/ci_scripts/venv/bin/python shebang

in ros2-linux\lib\console_bridge\cmake\console_bridge-config.cmake
Line 6: set(console_bridge_INCLUDE_DIRS “/home/rosbuild/ci_scripts/ws/install/include”)
Line 11: PATHS “/home/rosbuild/ci_scripts/ws/install/lib”

ros2-linux\local_setup.sh (2 hits)
Line 5: : ${AMENT_CURRENT_PREFIX:=/home/rosbuild/ci_scripts/ws/install}
Line 11: _ament_python_executable="/home/rosbuild/ci_scripts/venv/bin/python"
C:\Users\Geoffrey.Viola\Downloads\ros2-linux\setup.sh (1 hit)
Line 5: : ${AMENT_CURRENT_PREFIX:=/home/rosbuild/ci_scripts/ws/install}
ros2-linux\share*\local_setup.sh (1 hit)
Line 5: : ${AMENT_CURRENT_PREFIX:="/home/rosbuild/ci_scripts/ws/install"}
ros2-linux\share\ament_index\resource_index\parent_prefix_path*
/home/rosbuild/ci_scripts/ws/install

2

I will focus on the Linux release in this post. Can you please clarify what exactly you mean with “a lot of unexpected hard coded paths”. I could guess and will also comment on some classes of cases below but I think it would be helpful if you could state specific examples when referring to issues.

The following groups of cases are the ones I am aware of. If you noticed more cases please add them explicitly:

  • .sh scripts need to embed the absolute path. As long as you source .bash files (or similar) these fallback absolute paths in the .sh files won’t be used. sh does not have a mechanism to determine the absolute path of a sourced file so I assume this can not be fixed.

  • The shebang line for Python scripts. Python always uses the absolute path of the Python interpreter used to install the package. Since we use a virtualenv that makes it highly non-standard. Known issue for a long time: https://github.com/ros2/ros2/issues/141 Fixed by https://github.com/ros2/ci/pull/4

  • The parent_prefix_path files in the ament resource index. Fixed by https://github.com/ament/ament_cmake/pull/76

  • The SOURCES.txt files in Python eggs - shouldn’t matter. Fixed by https://github.com/ros2/ci/pull/5

  • The CMake config file of console_bridge. This is a package we use as-is from upstream so the problem should be addressed there.

  • The pkgconfig file of console_bridge. Afaik pkgconfig doesn’t support this so there might not be a way around that.

1 Like
3

Thanks Dirk. By “a lot of unexpected hard coded paths”, I meant that I wasn’t sure if they needed to be there or how they influence the system. You touched on all the details. They seemed like a red flag, but it sounds like you’re aware of them.

4

I took the opportunity to also look at the Windows archive and found the following cases:

  • The parent_prefix_path files (same as on Linux).

  • The SOURCES.txt files (same as on Linux).

  • The CMake config file of console_bridge.

So the list seems to be much shorter on Windows since:

  • .bat files can get their own path like .bash files can.

  • The Python scripts are actual executables (when been generated from an entry point).

  • No pkg_config on Windows.

Therefore I would conclude that we need to follow up on two items:

  • Double check on the ament resource index. Maybe there is a way to avoid absolute paths at least if they are referring to something within the same prefix where the resource is being stored in.

  • We really need to resolve the shebang line issue. I would think that even in a non venv the hardcoded path is a problem as it needs to match with the target system. Maybe instead we could postprocess the archive to rewrite the shebang line to something like /usr/bin/env python3. Not sure what others think of that idea?

5

Based on your post I spend some time on these “annoying details” and was able to resolve three of them:

I have updated the previous posts with the current state. If anyone has an idea how to resolve the remaining ones I would be more then happy to hear them. (Or if you would like to create a pull request for console_bridge please feel free to do so.)

1 Like