Side effects of sourcing a ROS2 workspace
Hello,
While working with ROS I find myself constantly having to source different stacks of overlays in various contexts such as plain old interactive shells, inside build scripts, in my editor, etc. It's quite a snag in my workflow to have to maintain and keep a mental note of the state I'm working in. To help the matters a bit I wrote a script: ws(1), which lets me list the names of workspaces to source. It goes searching through a predetermined list of "workspace root" paths for $workspace/(install)?/setup.bash files and sources them in order, while also adding an indicator for each found workspace to the PS1 variable.
Now, this is all fine and dandy on its own but there's still other things that make working with ROS more painful than I'd like. In particular, the useful state of, say, my shell sessions is rarely limited to just the active ROS workspaces. Starting with a humble working directory, random task-specific environment variables, all the way up to shell history and background jobs -- it's all part of a working context that I keep having to reconstruct if I find myself needing to switch or update to a different ROS workspace situation.
The (or, a part of) solution I had in mind was figuring out whether the activation of ROS workspaces could be safely reversed, at least so far as ROS itself is concerned, i.e. enough to let me source a different workspace (stack).
Which (alas) brings me to my question: What, exactly, are the expected side-effects of sourcing a ROS workspace? In particular, are the changes the process makes limited to manipulating the environment variables?
I probably could've found out the answer myself, but it seemed prudent (and faster) to ask people with deeper knowledge about the ecosystem and the hundreds of packages out there.
Hi @kvik can you be more specific on what do you mean by side effect?
Hey @osilva, I mean the set of changes to the system (or just the current process) that sourcing a
setup.bashproduces. An obvious side-effect is adding entries to the$PATH,$PYTHONPATH, etc. Such changes to the calling process' environment are easy to detect and therefore reproduce and/or reverse, but I'm wondering if it's possible for other changes to happen. An example would be creating symlinks, changing a configuration file, etc.Both seem unlikely because such globally visible changes would induce coupling between different active workspaces. However, I can imagine (convoluted) workarounds that someone might have employed, and without a deep knowledge of the build tools and the ecosystem I don't feel safe to assume otherwise.