verbs: adding locate verb to get workspace paths

[jbohren]

@k-okada

With this PR, calling this shell function from within a directory will source its devel space:

function source_devel() {
  source $(catkin locate --devel)/setup.bash
}

function source_devel() {
  source $(catkin locate --devel)/setup.zsh
}

cd to a package in the workspace, regardless of build_type (see #143)

function ccd() {
  cd $(catkin locate --src $1)
}

[k-okada]

thanks, this is perfect!

[wjwwood]

I'd suggest a trip-wire test for this verb, just to catch things like that.

Otherwise, lgtm.

[wjwwood]

nitpick: New files should get a 2015 copyright year.

[jbohren]

@k-okada @wjwwood I renamed the verb to catkin find and added an option to get the path to a workspace package. This also addresses usability concerns from #143.

[wjwwood]

Does this need to be update to include finding packages? I think it might work for both cases, though it is a little vague.

[wjwwood]

This also addresses usability concerns from #143.

By this I assume you mean it is addressed by using catkin find --pkg <package name> instead of roscd <package name>?

---

How does this compare or relate to catkin_find?

[jbohren]

This also addresses usability concerns from #143.
By this I assume you mean it is addressed by using catkin find --pkg instead of roscd ?

Yeah, specifically cd $(catkin find --pkg <package name>)

This will work from within a workspace in the same way catkin build <package name> will.

---

How does this compare or relate to catkin_find?

This is currently very different from catkin_find, which is used to find resources related to various projects. This is more like catkin_find_package and catkin find --pkg <package name> is the same as catkin_find_package <package name> /path/to/ws.

---

Another interface I was considering would have a form like:

catkin find pkg <package name>`
catkin find src
catkin find devel
catkin find install

[wjwwood]

Hmm, the find implies searching, but really it's a look up (finding a package does crawl, but in a limited scope).

I don't necessarily have a problem with the verb being called find, but maybe we should take a moment and consider the alternatives.

• catkin find
• catkin path
• catkin dir
• catkin loc[ation]
• catkin where[_is]

Others?

---

For reference brew has some -- options on the main command which provide similar info:

--cache
Display Homebrew's download cache. See also HOMEBREW_CACHE.

--cache formula
Display the file or directory used to cache formula.

--cellar
Display Homebrew's Cellar path. Default: /usr/local/Cellar

--cellar formula
Display the location in the cellar where formula would be installed, without any sort of versioned directory as the last path.

--env Show a summary of the Homebrew build environment.

--prefix
Display Homebrew's install path. Default: /usr/local

--prefix formula
Display the location in the cellar where formula is or would be installed.

--repository
Display where Homebrew's .git directory is located. For standard installs, the prefix and repository are the same directory.

[wjwwood]

Also the pull request description examples are identical (I think it might have been a copy paste update error).

[jbohren]

Hmm, the find implies searching, but really it's a look up (finding a package does crawl, but in a limited scope).

Yeah, other names are fine. I originally switched it from path because it wasn't very verb-y. I think catkin find and catkin locate would be my top two choices.

Also the pull request description examples are identical (I think it might have been a copy paste update error).

One is bash the other is zsh. Not really necessary to have both there of course.

[wjwwood]

What about this:

catkin locate {--source | -s [pkg_name], --devel | -d, --install | -i, --root | -r}

It combines --source and --pkg, since a package should always be in src somewhere.

[wjwwood]

These would also be good flags to put in the ws verb, so like this:

$ catkin ws --source
/tmp/my_ws/src
$ catkin ws --source rospy
/tmp/my_ws/src/ros_comm/clients/rospy
$ catkin ws --install
/opt/ros/indigo
...

[wjwwood]

Some other things to think about:

• What is the behavior when a package is not found?
• What happens if the install or devel space does not exist yet?
• Should the build space be an option too?
• Does this respect build profiles?

[jbohren]

These would also be good flags to put in the ws verb

Yeah that could also work, though I think a find or locate verb makes it clearer to use these features.

What is the behavior when a package is not found?

It returns an error code and prints a message to stderr.

What happens if the install or devel space does not exist yet?

Currently it will give you the path to where they will be created. I think it should also return nothing and print an error to stderr.

Should the build space be an option too?

It currently is and yes I think it should be.

Does this respect build profiles?

Yes. It gets the space paths from the context.

[jbohren]

@wjwwood What do you think of this interface:

usage: catkin find [-h] [--workspace WORKSPACE] [--profile PROFILE] [-e] [-r]
                   [-s | -b | -d | -i]
                   [PACKAGE]

Get the paths to various locations in a workspace.

optional arguments:
  -h, --help            show this help message and exit
  --workspace WORKSPACE, -w WORKSPACE
                        The path to the catkin_tools workspace or a directory
                        contained within it (default: ".")
  --profile PROFILE     The name of a config profile to use (default: active
                        profile)

Behavior:
  -e, --existing-only   Only print paths to existing directories.
  -r, --relative        Print relative paths instead of the absolute paths.

Sub-Space Options:
  Get the absolute path to one of the following locations in the given
  workspace with the given profile.

  -s, --src             Get the path to the source space.
  -b, --build           Get the path to the build space.
  -d, --devel           Get the path to the devel space.
  -i, --install         Get the path to the install space.

Package Directories:
  Get the absolute path to package directories in the given workspace and
  sub-space. By default this will output paths in the workspace's source
  space. If the -b (--build) flag is given, it will output the path to the
  package's build directory. If the -d or -i (--devel or --install) flags
  are given, it will output the path to the package's share directory in
  that space.

  PACKAGE               The name of a package to find.

[jbohren]

@wjwwood This is the next one in the queue, I believe.

[wjwwood]

Sorry, I've been letting this roll around in the back of my mind. I'm still not sold on using find. I think it should be reserved for replacing catkin_find which does something different than this and is more aptly named in my opinion. To be specific, find implies searching and the possibility for multiple results, which is true for what catkin_find does, but is not true for these actions. For the above options, there exists exactly one answer for each and since it is based on the profiles is just a lookup, not a search. So, I hope I can show that I'm not being capricious, but rather than the find verb really doesn't match these actions well.

I really think these options should be either attached to a different verb name, like locate (which I quite like), and/or added to the proposed ws command since they are ws specific once that is implemented.

Thoughts?

[wjwwood]

Oh, and other than the verb name, the above looks great to me.

[jbohren]

+1 for locate

[wjwwood]

I merged with rename.