CI is stuck on virtualenv 16.7.9 until install-scripts option is honored. about ci HOT 5 CLOSED

what is the rationale to install executables in $base/lib and not in $base/bin?

Excutables which should not be on the global path (bin) should be placed into lib/<pkgname to be ros2 run-able.

from ci.

what is the rationale to install executables in $base/lib and not in $base/bin?

@ivanpauno I think our desire comes from wanting to allow ROS packages to not worry about name collisions of their binaries with other ROS packages. That's why it's $base/lib/<my pkg>/my_executable

Excutables which should not be on the global path (bin) should be placed into lib/<pkgname to be ros2 run-able.

I remember this was justified by saying the binaries are not meant to be executed by the user directly (which they're not, they're executed by ros2 run), so they can be put into $base/lib/<pkg name> because that reason is acceptable in the FSH. Re-reading it, it looks like we got it a little bit wrong. $base/lib/<pkg> is incorrect. $base/usr/lib/<pkg> would be ok, but best of all we should actually be putting them into $base/usr/libexec/<pkg>.

2. We could make a case upstream that there should either be a way to opt-in to installation directory options in a virtual environment and provide patches to that end.

My reason for bringing the FSH up, can we make the case to upstream that we need the install options in a virtualenv to comply with the FSH for executables not meant to be executed by user's directly? I wonder if that justification would carry more weight than our own reasoning of wanting to avoid name collisions.

from ci.

what is the rationale to install executables in $base/lib and not in $base/bin?

If we want to still install executables in $base/lib, I think that options 2 or 3 are the best solutions.

from ci.

I've attempted possible solution (3) in this PR: colcon/colcon-core#530

from ci.

Is this still a work in progress? We used the old virtualenv version as a workaround as well but we are migrating to Debian 12 bookworm. Virtualenv 16.7.9 does not create a valid virtual environment anymore on this debian version.

Is there another workaround? The current version of colcon installed via pip in a virtual environment still ignores setup.cfg when building humble from source.

from ci.