This change allows specifying additional directories in which mixin files can be found. One or multiple directories can be provided through the COLCON_MIXIN_PATH environment variable. The mixins found in these director(y/ies) are available in addition to the ones found in COLCON_HOME.
Rationale
@mikepurvis and I are working on some changes which means that our colleagues will soon be using colcon instead of catkin when they build their workspace locally during development. With catkin we currently provide a profile to ensure the compile flags in developer workspaces are consistent with the ones used by the build system. With colcon we want to ensure similar behaviour. To achieve this we're setting a COLCON_HOME environment variable which points at a provided directory, in this directory we can provide mixins and a defaults file to ensure that invoking colcon build without any additional arguments uses the mixins we want (like the compilation flags).
However, we also want to enable individual devs to extend the provided mixins by writing their own. There can be only a single COLCON_HOME location, we wanted to avoid devs from having to make their own COLCON_HOME with symlinks to the provided mixin files (paths are also unstable, so links would break).
I explored using the COLCON_DEFAULTS_FILE, but using the mixin-files argument in that file doesn't work. I expect it's because of an interaction between the colcon-mixin and colcon-defaults plugins. I tried fixing this by copying these lines to line 164, but then the mixins are still not listed in the help file.
Instead, I think just allowing addition of arbitrary paths to be read for mixins is the most flexible, this also allows us to split out the mixins, instead of having to provide them all in a single COLCON_HOME directory. The mixins that are detected through this environment variable can be used from a COLCON_DEFAULTS_FILE. This means that developers can use mixins they developed in addition to the provided ones, and can use any of these mixins through the defaults file.
With this new environment variable it is easy for devs to extend the provided mixins with their own, and with the work by @jdlangs in https://github.com/colcon/colcon-defaults/pull/29 they can be easily consumed on a workspace-by-workspace basis, this allows for a development experience that's very close to catkin with its persistent configuration in the workspace.
A ci test failed because I used double quotes. I've pushed a fix for this. I couldn't really figure out how to properly run the unit tests locally so had to rely on the continuous integration catching that.
Proposed change
This change allows specifying additional directories in which mixin files can be found. One or multiple directories can be provided through the
COLCON_MIXIN_PATH
environment variable. The mixins found in these director(y/ies) are available in addition to the ones found inCOLCON_HOME
.Rationale
@mikepurvis and I are working on some changes which means that our colleagues will soon be using
colcon
instead ofcatkin
when they build their workspace locally during development. Withcatkin
we currently provide a profile to ensure the compile flags in developer workspaces are consistent with the ones used by the build system. Withcolcon
we want to ensure similar behaviour. To achieve this we're setting aCOLCON_HOME
environment variable which points at a provided directory, in this directory we can provide mixins and a defaults file to ensure that invokingcolcon build
without any additional arguments uses the mixins we want (like the compilation flags).However, we also want to enable individual devs to extend the provided mixins by writing their own. There can be only a single
COLCON_HOME
location, we wanted to avoid devs from having to make their ownCOLCON_HOME
with symlinks to the provided mixin files (paths are also unstable, so links would break).I explored using the
COLCON_DEFAULTS_FILE
, but using themixin-files
argument in that file doesn't work. I expect it's because of an interaction between thecolcon-mixin
andcolcon-defaults
plugins. I tried fixing this by copying these lines to line 164, but then the mixins are still not listed in the help file.Instead, I think just allowing addition of arbitrary paths to be read for mixins is the most flexible, this also allows us to split out the mixins, instead of having to provide them all in a single
COLCON_HOME
directory. The mixins that are detected through this environment variable can be used from aCOLCON_DEFAULTS_FILE
. This means that developers can use mixins they developed in addition to the provided ones, and can use any of these mixins through the defaults file.With this new environment variable it is easy for devs to extend the provided mixins with their own, and with the work by @jdlangs in https://github.com/colcon/colcon-defaults/pull/29 they can be easily consumed on a workspace-by-workspace basis, this allows for a development experience that's very close to
catkin
with its persistent configuration in the workspace.