search

colcon / colcon-core

Command line tool to build sets of software packages
http://colcon.readthedocs.io
Apache License 2.0
102 stars 46 forks source link

Overlaying workspaces via environment hooks #441

Open ojasjoshi opened 3 years ago

ojasjoshi commented 3 years ago

Hi,

I have a requirement to overlay a workspace(overlay_ws) but do not have the liberty to manually source the setup script in this overlay_ws. The idea is to inject an environment hook in the current workspace (that I can manually source) which sources the setup script in overlay_ws. Something as such,

// remote_workspace_overlay.bash.em

COLCON_CURRENT_PREFIX="/path/to/overlay_ws/setup/script"
source ${COLCON_CURRENT_PREFIX}/setup.sh
unset COLCON_CURRENT_PREFIX

The issue is that when this environment hook runs, the setup script in overlay_ws unsets some of the function variables such as unset _colcon_prefix_sh_source_script that are required to run rest of the subsequent environment hooks in the current workspace. Rightly so, this results in subsequent env-hooks to not run with _colcon_prefix_sh_source_script: command not found error.

A possible workaround for this is to buffer and reset the function variable _colcon_prefix_sh_source_script as such,

// remote_workspace_overlay.bash.em

local COLCON_PREFIX_SOURCE_BUFFER_FN=$(declare -f $_colcon_prefix_sh_source_script)
COLCON_CURRENT_PREFIX="/path/to/overlay_ws/setup/script"
source ${COLCON_CURRENT_PREFIX}/setup.sh
unset COLCON_CURRENT_PREFIX
eval "$COLCON_PREFIX_SOURCE_BUFFER_FN"

This however is largely dependent on the structure of the local_setup.sh script (for eg: env variable names, where these are set/reset etc.) and might not be the most robust solution.

Can you please suggest If the use of env-hooks and the workaround looks like a robust way to achieve this overlay and if not, what would be some other ways of achieving such an overlay with the constraints I have mentioned above.

mikepurvis commented 3 years ago

There might be some overlap here with my request in #365— basically, I feel that colcon's dsv-based handling of envvars is potentially quite powerful, and it would be great to figure out ways to expose more of those capabilities than the current scheme which pretty much just apes catkin's sequential overlay of merged and isolated workspaces.

For example, it should be fairly possible to have things like mixin workspaces (which I think is what you're asking for here), workspaces composed of disparate installspaces (which would be a good fit for systems like nix, guix, and spack), etc, but there's definitely some requirements-gathering that needs to happen as far as figuring out the best-fit way to manage it, but from an ergonomics but also implementation point of view.

All that to say, I think what you're want to do here with an env hook is probably safe, if a bit hacky, but may hold you over until something better exists. Depending on the number of packages in the remote overlay and how dynamic that is, you might be able to make this a bit simpler by sourcing the individual local_setup.sh of each one rather than workspace-level setup.sh.