add colcon_cd function

[dirk-thomas]

• colcon_cd <pkgname> will change the current working directory to the directory the specified package was found (usually in the source space)
  • if multiple locations are found they are all printed and the current working directory is switched to the first one
• colcon_cd changes the current working directory back to where the first command was called initially (usually the root of a workspace)

Requires colcon/colcon-core#240 and colcon/colcon-output#23.

[jacobperron]

A behavior of always preferring the workspace related to the current working directory seems more intuitive to me. And then falling back to a previous workspace if there was one.
But I'm not sure if there's a way to get the root of a colcon workspace from any subdirectory...

[dirk-thomas]

A behavior of always preferring the workspace related to the current working directory seems more intuitive to me.

Atm there is no way to determine a workspace root. See colcon/colcon-core#139 which is requiring a similar functionality.

And then falling back to a previous workspace if there was one.

For another underlay the only information about it is in the COLCON/AMENT_PREFIX_PATH which points to the install prefix which doesn't provide a way to derive the source directories of the packages in a reliable (non-heuristic) way.

The advantage of not requiring a workspace at all is that you can use the command anywhere in your file system.

[deitry]

Why this is not implemented as colcon subverb, like colcon cd? I respect colcon because there is no commands with underscores as it was with catkin_make and so on. Adding one will lead to unnecessary diversity and confusion.

[dirk-thomas]

Why this is not implemented as colcon subverb, like colcon cd?

@deitry Because a (Python) subprocess can't change the working directory of a shell. Therefore this functionality must be implemented as a shell function.

Regarding the naming of the function: in sh it is invalid to have dashes in function names.

[jacobperron]

IIUC, the assumed workflow is the command is initially called from within a workspace, or requires a colcon_cd --set if changing workspaces.

In the scenario where multiple copies of a package exist in a directory tree, the command fails. For example, if my directory tree is

.
├── ws1
│   └── src
│       └── foo
│           ├── CMakeLists.txt
│           ├── include
│           │   └── foo
│           ├── package.xml
│           └── src
└── ws2
    └── src
        └── foo
            ├── CMakeLists.txt
            ├── include
            │   └── foo
            ├── package.xml
            └── src

And I run colcon_cd foo, I get the following error:

Saved the directory '/home/jacob/ws/test_colcon_cd' for future invocations of 'colcon_cd <pkgname>' as well as to return to using  'colcon_cd'. Call 'colcon_cd --reset' to unset the saved path.
bash: cd: $'/home/jacob/ws/test_colcon_cd/ws1/src/foo\n/home/jacob/ws/test_colcon_cd/ws2/src/foo': No such file or directory

I think we could use a better error message about discovering multiple packages with the same name, and consider a fall-back behaviour to cd to the first instance.

I also can't use colcon_cd with ZSH, e.g.

$ colcon_cd rclpy
Could not find package 'rclpy' from the current working directory

And after trying colcon_cd --set:

Could neither find package 'rclpy' from '/home/jacob/ws/latest_ws' nor from the current working directory

[dirk-thomas]

I think we could use a better error message about discovering multiple packages with the same name, and consider a fall-back behaviour to cd to the first instance.

Yeah, it should definitely handle duplicate package names - done in: 2244869.

[dirk-thomas]

I also can't use colcon_cd with ZSH

Fixes in c9c66e8.

[jacobperron]

LGTM

[cottsay]

Requires colcon/colcon-core#240 and colcon/colcon-output#23.

Should this be reflected in setup.cfg? Or is a more of a soft requirement?

[dirk-thomas]

It doesn't strictly require those. If you have an older version it will just ignore the env var and generate a log directory`.

I will see if I add a version dependency anyway before releasing this... Thanks for the pointer.