new verb proposal: catkin info

[jbohren]

In #63 (comment) I proposed that in addition to a "build summary" after each build, catkin could also display certain advisories. These advisories, however, could be useful even when the user isn't performing a build, so there should be some other way to access them.

Where catkin_lint is for checking catkin packages for mistake this would be the main entry point for debugging problems with a catkin environment.

Example of the proposed usage and output:

$> catkin info 
Context:
  Current directory appears to be a Catkin workspace.
  A run-space in the current directory is currently sourced.
  Workspace stack:
  - /home/liza/my_overlay/devel
  - /home/liza/my_ws/devel
  - /opt/ros/hydro

Workspace: /home/liza/my_overlay
  Source-space: /home/liza/my_overlay/src
  Build-space: /home/liza/my_overlay/build
  Run-spaces:
  - /home/liza/my_overlay/devel

Possible advisories:

• Your source-space contains non-catkin packages, but you have not built into an install space.
• You've loaded a devel run-space from a workspace which also has an install run-space. You might have meant to load the install run-space.

Additionally, you could alias catkin wtf to run catkin info.

[NikolausDemmel]

+1

Since you mention catkin_lint, should that maybe be integrated with catkin_tools to be invoked automatically? I am not sure when would be an approiate time to invoke it though. Possibly as an default on option of the info/wtf command, and an default off option of the build commnad (performance concerns)?

Also, I would expect info to take package names as arguments. The information for a specific package could be the location it is found (current workspace, parent workspace), and possibly also if there are additional 'shadowed' instances of this packge further down the workspace chain. Moreover info like what kind of package (catkin, cmake, meta-package) it is and whether/when it has been built/installed last (if that is technically feasable) could be displayed.

[jbohren]

Since you mention catkin_lint, should that maybe be integrated with catkin_tools to be invoked automatically? I am not sure when would be an approiate time to invoke it though. Possibly as an default on option of the info/wtf command, and an default off option of the build commnad (performance concerns)?

Yeah I'm not sure we want to run it automatically, but I suggested over in fkie/catkin_lint/issues/12 if lint should be added as a verb.

Also, I would expect info to take package names as arguments. The information for a specific package could be the location it is found (current workspace, parent workspace), and possibly also if there are additional 'shadowed' instances of this packge further down the workspace chain.

Yeah this would be supported by context-aware verb functionality also needed to be able to build a specific package or workspace just by calling catkin build from the package directory.

[NikolausDemmel]

Yeah this would be supported by context-aware verb functionality also needed to be able to build a specific package or workspace just by calling catkin build from the package directory.

+1

[jack-oquin]

+1 to catkin info

I expect it would be useful to provide info on:

• the whole workspace
• one or more named packages
• the package in the current directory subtree

Not sure which the default should be.

[tkruse]

Not sure how you want to identify the build and run-spaces. Catkin obviously allows the user to create hundreds of run-spaces (debug, release, arm) all over you filesystem if he wishes so, and catkin will not keep track of those for the user AFAIK.

Also note that while this is all wonderful information, the largest intended user group does e.g. not know what a run-space is, nor cares to learn about it. That is not a argument against more information, just a reminder to provide enough information that an uninitiated reader can grasp what is going on. As a simple example (not criticism), your draft lists a "workspace stack". So the label "workspace stack" is not to be found in any catkin documentation, nor is it clear which direction the chain is, nor what the effect is. Compare to:

´´´
ROS packages will be looked up in folders in this order:

• /home/liza/my_overlay/devel
• /home/liza/my_ws/devel
• /opt/ros/hydro
  ´´´

Also I believe the necessity for displaying vital information rather indicates catkin_tools should strive to be far more restrictive than catkin with much less possible variation in the folder layout.

Also remember that for a development workspace, there are always 3 use-cases:

1. building the packages inside
2. running the packages inside
3. building against the packages inside.

Both case 2+3 require a run-space to be sourced, while for case 1, for pristine results, no runspace of this workspace should be sourced. So the names "build-space" and "run-space" may be more confusing than helpful, they are esoteric. I would suggest using names for spaces that relate to the content of the spaces, not processes about the spaces. I wish I had a good suggestion, too.

[NikolausDemmel]

Not sure how you want to identify the build and run-spaces. Catkin obviously allows the user to create hundreds of run-spaces (debug, release, arm) all over you filesystem if he wishes so, and catkin will not keep track of those for the user AFAIK.

Commands like catkin info should consider the src/build/devel/install spaces that would be used by catkin build with the same arguments (i.e. it should support options like --space-suffix). Having said that, hasn't it been proposed already that the marker file might contain named build configurations, that store options like the corresponding sourc/build/devel/install space locations, additional cmake arguments, etc... These could be created e.g. with catkin build --create-config release --space-suffix release -DCMAKE_BUILD_TYPE=Release and later invoked with catkin build --config release. These named configurations could be interesting in particular for direct IDE integration. Otoh this opens up more ways to use catkin_tools rather than being more restrictive as you suggest.

[tkruse]

There are plenty of nice ideas of how to either fill a marker file with meta-data, or how to place such meta-data in files relative to the marker file. But those are just ideas for now. (And realizing those is more complex than just writing meta-data into a file, BTW.)

If that were to be changed, then a command like catkin info could become obsolete, as it could be replaceable by cat workspace.conf, which is also much more IDE-friendly.

[NikolausDemmel]

There are plenty of nice ideas of how to either fill a marker file with meta-data, or how to place such meta-data in files relative to the marker file. But those are just ideas for now. (And realizing those is more complex than just writing meta-data into a file, BTW.)

Agreed. Edit: What I meant to say is that until some implements this, catkin info should chose build/devel/result spaces as catkin build would.

If that were to be changed, then a command like catkin info could become obsolete, as it could be replaceable by cat workspace.conf, which is also much more IDE-friendly.

catkin info would be for user consumption and IDE's could read/manipulate the marker file directly (if well specified). Like with git, you can access/change the config through the CLI or by editing .git/config manually, whatever you prefer.

In particular catkin info it should explain things like extended workspaces in English and in a way that in particular novice users hopefully understand better than a mere extends: work/space/path/a work/space/path/b in a .conf file.

[wjwwood]

Your source-space contains non-catkin packages, but you have not built into an install space.

Slightly OT, but why is this an advisory? Assuming you mean "...you have built into a devel space but not an install space...", I think that is a perfectly valid scenario.

[jbohren]

This is handled by the catkin config verb implemented in #80 and the new context summary.