entry_points install path is now 'bin' instead of 'lib' for setup.py installs

[dustingooding]

I believe a regression has been introduced with the merging of 5203c99 (or I'm holding something wrong).

With colcon-core at 0.9.0, the test_py_package fails to execute it's entry_points scripts.

I created a workspace, added the content of https://github.com/colcon/colcon-bundle/tree/master/integration/ros2_workspace/src/test_py_package to the workspace and built.

When executing the run_py_package_tests script, I get:

# ros2 run test_py_package run_py_package_tests
No executable found

The install space for the workspace looks like this:

# tree -L 3
.
├── COLCON_IGNORE
├── _local_setup_util_ps1.py
├── _local_setup_util_sh.py
├── local_setup.bash
├── local_setup.ps1
├── local_setup.sh
├── local_setup.zsh
├── setup.bash
├── setup.ps1
├── setup.sh
├── setup.zsh
└── test_py_package
    ├── bin
    │   └── run_py_package_tests
    ├── lib
    │   └── python3.8
    └── share
        ├── ament_index
        ├── colcon-core
        └── test_py_package

8 directories, 12 files

Previously, with colcon-core at 0.8.3, the run_py_package_tests executable was located in lib as a cousin to the python3.8 directory.

Downstream, this is causing other issues with things like launch files, with errors like "libexec directory '/path/to/workspace/
install/pkg_name/lib/pkg_name' does not exist"

[devenpatel2]

a workaround that seems to work for me is this

colcon build --symlink-install
colcon build

this creates the necessary directory in install/<package_name>/lib/<package_name>

[mr337]

a workaround that seems to work for me is this

colcon build --symlink-install
colcon build

this creates the necessary directory in install/<package_name>/lib/<package_name>

Was recently bit by this on our CICD pipeline as colcon-core 0.8.3 upgraded. Can confirm this work around is great.

[Guillaumebeuzeboc]

Faced the same issue.
In the setup.cfg I replaced

[develop]
script-dir=$base/lib/my_package
[install]
install-scripts=$base/lib/my_package

By

[develop]
script_dir=$base/lib/my_package
[install]
install_scripts=$base/lib/my_package

(so replacing dashes from variable's name by underscores)

[ralwing]

Yet another workaround is setting env variable:

SETUPTOOLS_USE_DISTUTILS=stdlib

Which will switch SETUPTOOLS to default system version included in installed python version.
https://github.com/pypa/setuptools/blob/main/CHANGES.rst#breaking-changes-5

Unfortunately, this workaround won't work soon.
And also will not work for Python >= 3.12