Trouble handling multiple sourced underlay workspaces

[Ross Lunan]

On my Ubuntu 24.04/ROS 2 Desktop, I have the usual /opt/ros/jazzy underlay. I also have a /ros2_ws overlay workspace for my robot work that is sourced into the .bashrc. Then I configured a second workspace second_ws to try out a package that I colcon build and sourced in the root directory . install/local_setup. It is NOT sourced in the .bashrc . All ok. Then I want to delete the second_ws workspace by deleting build install log.Close the Terminal Window, Open a new window which generates an error : not found: "/home/ubuntu/second_ws/install/local_setup.bash". Where does this come from? I recall reading there is a concept of "chained workspaces" that extends the environment  to existing workspaces  from new ones. And tried this for multiple workspaces" Workspace Handling with no benefit. Anybody encountered this behavior and how to clean up ridding the system and cleaning up undesired workspaces?

[Karim Virani]

Like it says in the stack exchange article you linked, you have to be very careful about terminal and build management when you have multiple workspaces. You could have inadvertently done a colcon build in your primary overlay workspace from a terminal where you had previously built and sourced your secondary workspace prior to deleting it. Have you gone back and deleted your primary ws build, install and log directories and rebuilt it? 

On Tue, Sep 9, 2025 at 2:37 PM 'Ross Lunan' via HomeBrew Robotics Club <hbrob...@googlegroups.com> wrote:

On my Ubuntu 24.04/ROS 2 Desktop, I have the usual /opt/ros/jazzy underlay. I also have a /ros2_ws overlay workspace for my robot work that is sourced into the .bashrc. Then I configured a second workspace second_ws to try out a package that I colcon build and sourced in the root directory . install/local_setup. It is NOT sourced in the .bashrc . All ok. Then I want to delete the second_ws workspace by deleting build install log.Close the Terminal Window, Open a new window which generates an error : not found: "/home/ubuntu/second_ws/install/local_setup.bash". Where does this come from? I recall reading there is a concept of "chained workspaces" that extends the environment  to existing workspaces  from new ones. And tried this for multiple workspaces" Workspace Handling with no benefit. Anybody encountered this behavior and how to clean up ridding the system and cleaning up undesired workspaces?

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/0924975b-115e-4455-9b30-53e35d492f03n%40googlegroups.com.

[Michael Wimble]

What Karim says, likely.

When you do ’source install/setup.bash”, here’s what AI said as a summary of what happens:

• AMENT_PREFIX_PATH: This variable is updated to include the install directory of the current workspace, ensuring that ROS 2 can find packages and resources within this overlay.
• PATH: The install/bin directory of the workspace is added to the PATH, allowing direct execution of executables built within the workspace without specifying their full path.
• PYTHONPATH: The install/lib/pythonX.Y/site-packages directory (where X.Y is your Python version) is added to PYTHONPATH, enabling Python to locate ROS 2-related modules and packages.
• ROS_PACKAGE_PATH: This variable, while less prominent in ROS 2 compared to ROS 1, can still be affected to ensure package discovery.

But when you build a workspace, especially if you rebuild your first worspace, it captures the overlay stack at the time of the build. So if you rebuild the first workspace while the second workspace was in your overlay stack, it would have captured that. If you deleted the second workspace and do ’source install/bash.sh’ on the first workspace again, it had already captured the fact that the second workspace was in the overlay stack and would complain.

I’m not sure I explained that well, but it comes down to every time you build a workspace, it captures the overlay stack in existence at the time of the build and doing a ’source install/setup.bash’ on that workspace later, if some workspace in the stack has since disappeared it will complain — just exactly the behavior you are seeing. So, if you, indeed, rebuilt the first workspace after having built the second workspace and also doing a source of it’s setup.bash (using the same terminal), you’ll get just the behavior you saw.

If that isn’t what happened, I’d have to hear more details.

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CAKtnkiyjmP%3DF_sxt0nK8VkjpBgTGSU_iAC7H36NBaR0TM1YVqA%40mail.gmail.com.

[Ross Lunan]

Michael, Yes, it appears that's what happened and thanks. So the question is, CanI and how do I repair the installation, and maybe at the same time how do I remove the second overlay workspace that I no longer want whose stack was captured by the first overlay?  Maybe I should start over by with a new Ubuntu Install rebuilding the whole Desktop and in future be more careful configuring additional overlays. But now  I have several other workspaces in my Desktop that I created earlier to experiment with various repos, but no longer want.  If I simply delete them, I'll probably run into this same issue. The Colcon Instructions actually caution about this suggesting to source with "install/local_setup.bash". Ross

[Michael Wimble]

Nothing so radical. Just:

cd my_ws

rm -rf build install log

colcon build —symlink install

source install/setup.bash

And Bob’s your uncle.

If you source an workspace and want to back it out, you can:

1. Kill the terminal, and just to the ’source install/setup.bash’ of the overlays in the order you want. This is what I usually do.

2. You can munch the AMEND_PREFIX_PATH and PATH and PYTHON_PATH and ROS_PACKAGE_PATH variables to remove packages from the list you don’t want anymore (wear a large red ’S’ on your shirt if you do this correctly the first time).

I haven’t looked a local_setup.bash vs setup.bash. 

Keep in mind that you can add the same thing to the stack multiple times, and I sometimes do this. You can:

source opt…

source A

source B

souce opt

source A

and B will only show up if you try to actually access something in B that isn’t defined in A and opt. But, practically, you’re better off, if you don’t mind losing all the stuff in the terminal log, to just kill off your terminal and do the sources again.

And, in case you don’t know, .bashrc is ’sourced’ by the terminal when you start one. There are other ways to executed software that don’t involve doing something from a terminal and those other ways don’t know about .bashrc. Especially, if you set up your robot code to startup at boot time, using the usual magic, it won’t involve running a terminal and you have to do, yourself, all the things in .bashrc that you want to happen.

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/69ab5e58-3387-44bf-9984-36edc3c4a2f1n%40googlegroups.com.

[Charles de Montaigu]

Ross,

Look at Nav2 build from source documentation. It uses a stack workspace.

Nav2

Bonds Heartbeat

ROS2

Workspace stack. Source layer below it as I recall 

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/775E7541-E77D-4F51-A25F-D3F8965AEF20%40gmail.com.

[Ross Lunan]

    The saga continues: I discovered that the "not found: "/home/ubuntu/a_ws/install/setup.bash " error message on my machine is being generated by the "source chained prefixes" feature in the  /install/setup.bash script by another previously colcon build compiled package, say a_ws in Mike's example in the same ~/ directory that was colcon build after the b_ws package was already built and sourced . With normal practice there is a "source /home/ubunt/a_ws/install/setup.bash in the .bashrc. So the a_ws/install/setup.bash file includes a line "COLCON_CURRENT_PREFIX=/home/ubuntu/b_ws/install" . i.e chained.  Consequently if the b_ws package is deleted, the very next time a_ws is sourced when .bashrc is run the "not found" message is generated by a_ws.      

       The solution to delete the 2nd "B" workspace is 1) In a Terminal delete b_ws 2) cd a_ws 3) colcon build symlink-install 4)  Source a_ws by . install/setup.bash. Ta da.                                                                                                  When experimenting with several workspaces and don't want chaining - be careful. When a 2nd "B" workspace is colcon build and sourced, and you go back and colcon build and source the 1st  earlier "A" workspace the chain function will add the 2nd workspace to  the "A" install/setup.bash, laying in wait to generate an error message when you delete "B"   Many thanks to Karim and Michael & hope this helps others. I expect this behavior is written somewhere but I was unable to find even with AI. 
Ross

[Marco Walther]

If you want to 'delete a previously included workspace' out of the
middle of your 'stack', anything after that might be broken. So, you
would have to clean & build all the later WSs again. There is no defined
way around that.

Maybe you know, that the different WSs don't depend on each other, but
the general setup can NOT make that assumption. So if you're sure, you
can do surgery, but at that point, you're on your own;-)

-- Marco

>> * |AMENT_PREFIX_PATH|: This variable is updated to

>> include the |install| directory of the current
>> workspace, ensuring that ROS 2 can find packages and
>> resources within this overlay.

>> * |PATH|: The |install/bin| directory of the workspace
>> is added to the |PATH|, allowing direct execution of

>> executables built within the workspace without
>> specifying their full path.

>> * |PYTHONPATH|: The |install/lib/pythonX.Y/site-
>> packages| directory (where X.Y is your Python version)
>> is added to |PYTHONPATH|, enabling Python to locate

>> ROS 2-related modules and packages.

>> * |ROS_PACKAGE_PATH|: This variable, while less

>>> for multiple workspaces" Workspace Handling <https://
>>> robotics.stackexchange.com/questions/113595/ros2-
>>> recommended-handling-of-workspace-setup-bash> with no

>>> benefit. Anybody encountered this behavior and how to
>>> clean up ridding the system and cleaning up undesired
>>> workspaces?
>>>
>>> --
>>> You received this message because you are subscribed
>>> to the Google Groups "HomeBrew Robotics Club" group.
>>> To unsubscribe from this group and stop receiving
>>> emails from it, send an email to
>>> hbrobotics+...@googlegroups.com.
>>> To view this discussion visit https://
>>> groups.google.com/d/msgid/

>>> hbrobotics/0924975b-115e-4455-9b30-53e35d492f03n%40googlegroups.com <https://groups.google.com/d/msgid/hbrobotics/0924975b-115e-4455-9b30-53e35d492f03n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>>
>>>
>>> --
>>> You received this message because you are subscribed to
>>> the Google Groups "HomeBrew Robotics Club" group.
>>> To unsubscribe from this group and stop receiving emails
>>> from it, send an email to hbrobotics+...@googlegroups.com.
>>> To view this discussion visit https://groups.google.com/
>>> d/msgid/hbrobotics/

>>> CAKtnkiyjmP%3DF_sxt0nK8VkjpBgTGSU_iAC7H36NBaR0TM1YVqA%40mail.gmail.com <https://groups.google.com/d/msgid/hbrobotics/CAKtnkiyjmP%3DF_sxt0nK8VkjpBgTGSU_iAC7H36NBaR0TM1YVqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>>
>>
>> --
>> You received this message because you are subscribed to the
>> Google Groups "HomeBrew Robotics Club" group.
>> To unsubscribe from this group and stop receiving emails from
>> it, send an email to hbrobotics+...@googlegroups.com.
>> To view this discussion visit https://groups.google.com/d/
>> msgid/

>> hbrobotics/69ab5e58-3387-44bf-9984-36edc3c4a2f1n%40googlegroups.com <https://groups.google.com/d/msgid/hbrobotics/69ab5e58-3387-44bf-9984-36edc3c4a2f1n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the
> Google Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to hbrobotics+...@googlegroups.com.
>
> To view this discussion visit https://groups.google.com/d/msgid/

> hbrobotics/775E7541-E77D-4F51-A25F-D3F8965AEF20%40gmail.com
> <https://groups.google.com/d/msgid/hbrobotics/775E7541-
> E77D-4F51-A25F-D3F8965AEF20%40gmail.com?
> utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to hbrobotics+...@googlegroups.com

> <mailto:hbrobotics+...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> hbrobotics/284c2a91-40df-48ab-8908-75a5c10f6130n%40googlegroups.com
> <https://groups.google.com/d/msgid/
> hbrobotics/284c2a91-40df-48ab-8908-75a5c10f6130n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[Ross Lunan]

As a postscript on this matter, here's a robotics.stackexchange.com post Colcon Build Automatic Chaining