Optional automatic `source install/setup.bash` in cwd when using ROS 2 CLI commands

ROS ROS General
1

One of the most tedious parts of ROS 2 is repeatedly calling source install/setup.bash in every new workspace terminal. I’m suggestion an optional environment variable that, when enabled, automatically runs source install/setup.bash (or other shell equivalent) when CLI commands including ros2 run, launch, topic, msg, param, action, service, ... are called. This would restrict the user’s ability to call these commands anywhere except the root of the intended workspace. However, I find that to be a worthwhile tradeoff that many CLI tools outside of ROS 2 already do, but would be interested to know if others feel the same way. Again, completely optional non-default behavior.

The specific logical flow would be:

  1. User calls ros2 ... from their workspace root
  2. Code in ros2cli checks if an “auto-source” environment variable is set
  3. If it’s set, then run source install/setup.<shell_extension>
  4. Finally, the intended command is run

Side note: this idea could be extended to auto colcon build before ros2 run/launch as well.

1 Like
2

If you’re working in signle workspace adding
“source install/setup.bash”
To your ~/.bashrc can solve this.

3

That would cause an error to pop up every time you open a new terminal outside of a workspace, alongside other unintended consequences.

4
  1. ROS is not sourced
  2. You call ros2 …
  3. Command not found

So you assume at least /opt/ros/lithium is sourced?

5

I think you’re confusing sourcing the underlay with sourcing the workspace overlay. Most people have source /opt/ros/jazzy/setup.bash in their ~/.bashrc, which sources the underlay automatically. That is what gives you ros2 as a command.

1 Like
6

I think that there’s a lot of other potential solutions that don’t add complexity to the tools.

For example you can setup a bash alias to do exactly what you’ve outlined above for any commands you want to add this indirection for, such as ‘ch’ for colcon here: alias colconh='. install/setup.bash colcon'

However I would not suggest trying to bundle the operations. Sourcing your environment on every execution sounds like a lot of complexity and potentially could cause collisions if you reuse a terminal between workspaces.

A generic alias to source the current root is the same number of lines in your .bashrc as an environment variable. alias ws='source install/setup.bash or pick your own shortcut name.

Or you can setup aliases to help you manage your workspaces. Many people have a couple character shortcut aliases to setup their workspaces. As an example you could do something like alias ws1='. ~/my/first_workspace/install/setup.bash'

Then you just type ws1 any time you want to use that workspace in a terminal. This keeps the workspace management from being coupled from the commands. You can setup configs for each workspace or if you’d like to do more you can add arguments or more complexity in bash functions too.

1 Like
7

The reason I bring this up against every user creating their own alias for it is that it’s a common workflow. The issues you mention are largely the same as someone sourcing across workspaces in one terminal regardless of any other command. I don’t think it the implementation would be particularly complex either, aside from some autocompletion quirks that may arise. There’s also other options like direnv, but really this should be a commonplace option included in ROS 2 in my opinion.

8

The other thing to note is that running source from Python is non-trivial and at the very least its “tricky” to affect the bash environment from inside a Python process.

Rather than custom alias commands for each workspace, I use source_ros to automatically source the setup.bash of the workspace, which works regardless of whether you are at the workspace root or not.

1 Like
9

Did you know you can make ros2 an alias that in turn uses the original ros2? Maybe this is what you want?

alias ros2='if [[ $ROS_VERSION != 2 ]]; then \
    if [[ -e install/setup.bash ]]; then \
      . install/setup.bash; \
    else \
     . /opt/ros/galactic/setup.bash; \
    fi; \
  fi; \
  ros2'

Since it checks the env var first thing, it’s minimal overhead after the first invocation.

2 Likes
10

Also, note that sourcing can take considerable time in some workspaces.

11

I’m not going to add any more on why it would not be a good idea to source it on every ros2 command call but I wrote this small bash tool which might be useful for you:

Using MultiEnv you can add environments in the form of short bash snippets (e.g. to source your workspace and define workspace related aliases, etc.).
The tool is added to the bashrc and when it is sourced checks which environment is currently active and sources the relevant snippet.

This way turning off ROS becomes as simple as

multienv switch none

and switching between workspaces is as simple as

multienv switch jazzy
....
multienv switch rolling

It has more options (full auto-complete) and can also switch only the current terminal.

I originally wrote it because Anaconda did not like working with ROS, but it’s still very useful for me even though I don’t use Anaconda anymore.

1 Like
12

Actually it works quite well. That is precisely the purpose of the RoboStack project with support for noetic, humble and jazzy, for MacOS (arm and intel), Windows and Linux (arm and intel). It’s my go-to approach for deploying ROS on robot hardware - like Raspberry Pi as it works with the native Debian OS.

1 Like
13

You could use something like direnv that allows to call commands automatically (like sourcing a file) when entering a directory from your shell.

14

I think there is a misunderstanding that I’m seeing here. I don’t need this for myself. I know how to make an alias for ros2 and how to use direnv. This question was originally brought up by someone else in the Discord, and it’s extremely common for people to source then run a ros2 command in a new terminal. So common that it should be an option that users can easily opt into if they don’t want to deal with this themselves. As I’ve mentioned in the Discord message chain on this, you could certainly offer the alias, but there might be quirks with autocompletion that might need to be dealt with at the lower level. While I don’t think this would be trivially easy, I don’t think it would be impossibly difficult to implement either. Most people that I have worked with have a simple workflow that would be much more convenient if they didn’t have to spam source for their overlays, and didn’t have to write a custom alias on every new system they use.

1 Like