Problem:

When running colcon build --symlink-install --merge-install, on multiple python packages (via a setup.py), sometimes a subset of the packages are inaccessible, despite otherwise installing fine (eg. a ModuleNotFoundError)

Steps to reproduce:

Run colcon build --symlink-install --merge-install on a source tree with multiple python packages.
Since this is a parallelization issue, it will not always occur. (eg. system/load dependent)

Hypothesis:

When a python package is installed in symlink mode, an '.egg-link' and line in 'easy-install.pth' are added to install/lib/python3.7/site-packages/, which references the package's respective directory in build.

However, if multiple install operations attempt to edit 'easy-install.pth' simultaneously, the changes made by one package are negated by the subsequent changes of the other package.

For instance, if I watch 'easy-install.pth' at a high enough poll rate, I can see the path for package1 being appended. Shortly after the entry for package1 disappears and package2 appears.

Possible Solution:

Disable parallel for python packages installed via a setup.py when using symlink install.

When running colcon build --parallel-workers 1 on cpp code the number of compiler threads is not 1.
To have the "expected" behaviour I should run instead

export MAKEFLAGS=-j1
colcon build --parallel-workers 1

Is this behaviour intended?
Is it possible to cite this fact directly in the colcon documentation?

Thank you very much!

I have tried to build Autoware as

colcon build --symlink-install --merge-install  \
--cmake-args -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF

and my 24-core system literally dies (no response, need to reboot). top shows all cc1plus processes are in D = uninterruptible sleep

The only escape is to add --executor sequential Something is wrong with the way the colcon-parallel-executor works.

I'm using docker to build it:

rocker -e LIBGL_ALWAYS_SOFTWARE=1 --x11 --user --volume $HOME/github/autowarefoundation/autoware/ -- ghcr.io/autowarefoundation/autoware-universe:latest-cuda

colcon build --symlink-install --merge-install  \
--cmake-args -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF

When an exception is raised in a task using the sequential executor in colcon_core, the executor stops processing jobs immediately regardless of the on_error behavior and returns 1.

In the parallel executor, it seems that exceptions are treated the same as a non-zero exit code and on_error is used to determine the behavior.

The resulting error message in the colcon executor code makes it sound like the exception originated from an error in the executor itself, but the return code does eventually get changed to 1 to match the sequential executor. Regardless, the on_error behavior difference is noteworthy.

Running colcon as top level process isn't always possible, and sometimes, colcon is run as part of a larger build (build server, pytest, etc.)

Is it possible for the parallel executor to conform to be a good jobserver interactive citizen? Example of existing implementation: https://pypi.org/project/pytest-jobserver/

Link to jobserver client requirements: https://www.gnu.org/software/make/manual/html_node/POSIX-Jobserver.html