Investigate automatic support for autocomplete integration

[traversaro]

YARP (and possibly other projects) support autocomplete integration as discussed in robotology/community#15 . However, the proposed procedure require to create a symbol link in global directories. To permit automatic and non-invasive integration, we should understand if we enable it on a process-specific level by doing something in our "activation script" setup.sh .

[drdanz]

From the readme in https://github.com/scop/bash-completion/

Q. Where should I install my own local completions?

A. Put them in the completions subdir of $BASH_COMPLETION_USER_DIR
(defaults to $XDG_DATA_HOME/bash-completion or
~/.local/share/bash-completion
if $XDG_DATA_HOME is not set) to have them loaded on demand.
See also the next question's answer for considerations for these
files' names, they apply here as well. Alternatively, you can write
them directly in ~/.bash_completion which is loaded eagerly by
our main script.

I've never tried if this works, but I think we can put there a file that loads all the files installed in the <superbuild_install_path>/share/bash-completion/completions/
Or we could change the BASH_COMPLETION_USER_DIR environment variable, but it's more invasive in case the user wants to use his own scripts in that path.

[traversaro]

I just used for the first time for a real task the YARP conda binaries, and while they are working fine, the absence of bash completion is a real usability problem.

[traversaro]

From the readme in https://github.com/scop/bash-completion/

Q. Where should I install my own local completions?
A. Put them in the completions subdir of $BASH_COMPLETION_USER_DIR
(defaults to $XDG_DATA_HOME/bash-completion or
~/.local/share/bash-completion
if $XDG_DATA_HOME is not set) to have them loaded on demand.
See also the next question's answer for considerations for these
files' names, they apply here as well. Alternatively, you can write
them directly in ~/.bash_completion which is loaded eagerly by
our main script.

I've never tried if this works, but I think we can put there a file that loads all the files installed in the <superbuild_install_path>/share/bash-completion/completions/
Or we could change the BASH_COMPLETION_USER_DIR environment variable, but it's more invasive in case the user wants to use his own scripts in that path.

Actually it seems we don't need to interfere with user-specified completion scripts, the following Q is related to installation:

Q. I author/maintain package X and would like to maintain my own
completion code for this package. Where should I put it to be sure
that interactive bash shells will find it and source it?

A. Install it in one of the directories pointed to by
bash-completion's pkgconfig file variables. There are two
alternatives:

• The recommended directory is completionsdir, which you can get with
  pkg-config --variable=completionsdir bash-completion. From this
  directory, completions are automatically loaded on demand based on invoked
  commands' names, so be sure to name your completion file accordingly, and
  to include (for example) symbolic links in case the file provides
  completions for more than one command. The completion filename for
  command foo in this directory should be either foo, or foo.bash.
  (Underscore prefixed _foo works too, but is reserved for
  bash-completion internal use as a deprecation/fallback marker.)
• The other directory which is only present for backwards compatibility,
  its usage is no longer recommended, is compatdir (get it with
  pkg-config --variable=compatdir bash-completion). From this
  directory, files are loaded eagerly when bash_completion is loaded.

At least on Ubuntu, we have:

traversaro@IITICUBLAP102:~$ pkg-config --variable=completionsdir bash-completion
/usr/share/bash-completion/completions

and YARP already installs in the ${CMAKE_INSTALL_DATADIR}/bash-completion/completions:
https://github.com/robotology/yarp/blob/v3.4.5/data/bash-completion/CMakeLists.txt#L8

At this point, we just need to tell bash_complete to consider the robotology-superbuild installation prefix. This is done by adding the <install_prefix>/share to XDG_DATA_DIRS, see:

• https://github.com/scop/bash-completion/blob/2.11/bash_completion#L2180
• https://bugzilla.redhat.com/show_bug.cgi?id=1264094

At this point, it seems that the only missing pieces are:

• Add <install_prefix>/share to XDG_DATA_DIRS in the setup scripts and docs
• As the rule is that "The completion filename for command foo in this directory should be either foo" probably we need to install the same file in yarp-config, yarprun and yarpserver to support also those commands?

[drdanz]

• Add <install_prefix>/share to XDG_DATA_DIRS in the setup scripts and docs

👍🏻
This might also save you from setting YARP_DATA_DIRS (unless there are repositories that do not install yarp stuff there)

• As the rule is that "The completion filename for command foo in this directory should be either foo" probably we need to install the same file in yarp-config, yarprun and yarpserver to support also those commands?

I just realized we have completion for those commands...
Perhaps a symbolic link is enough to get them working?

[traversaro]

• Add <install_prefix>/share to XDG_DATA_DIRS in the setup scripts and docs

👍🏻
This might also save you from setting YARP_DATA_DIRS (unless there are repositories that do not install yarp stuff there)

Really? That would be a dream. However from http://www.yarp.it/git-master/resource_finder_spec.html it seems that XDG_DATA_DIRS only adds the yarp subdirectory of XDG_DATA_DIRS, so I am afraid that if we don't set YARP_DATA_DIRS , we break all the non-YARP projects.

[traversaro]

• As the rule is that "The completion filename for command foo in this directory should be either foo" probably we need to install the same file in yarp-config, yarprun and yarpserver to support also those commands?

I just realized we have completion for those commands...
Perhaps a symbolic link is enough to get them working?

Probably yes, I was preferring just to copy on install as it is easier to do at CMake level and creates less problems (for example on Windows).

[traversaro]

By the way, I just tested with https://github.com/robotology/icub-gazebo-grasping-sandbox that actually has completion thanks to /usr/local/share/bash-completion/completions. On a new terminal, the yarpserver autocomplete indeed does not work, but as soon as the autocomplete for yarp is run once, the script is executed, and yarpserver completion works as well.

[drdanz]

Really? That would be a dream. However from http://www.yarp.it/git-master/resource_finder_spec.html it seems that XDG_DATA_DIRS only adds the yarp subdirectory of XDG_DATA_DIRS, so I am afraid that if we don't set YARP_DATA_DIRS , we break all the non-YARP projects.

That's the reason why we have path.d, if all the software is installed in the same prefix, the non-yarp projects will install their .ini file in the right directory and yarp will find the required paths. I've been using this for years on my system, and I'm pretty sure that this works, at least for the repositories properly installing stuff.

Probably yes, I was preferring just to copy on install as it is easier to do at CMake level and creates less problems (for example on Windows).

I got the impression that with recent CMake versions, symbolic links should be partially working also on windows (perhaps copying the file instead of creating a link, like for file(CREATE_LINK ... COPY_ON_ERROR)), but I have never tried.

[traversaro]

Really? That would be a dream. However from http://www.yarp.it/git-master/resource_finder_spec.html it seems that XDG_DATA_DIRS only adds the yarp subdirectory of XDG_DATA_DIRS, so I am afraid that if we don't set YARP_DATA_DIRS , we break all the non-YARP projects.

That's the reason why we have path.d, if all the software is installed in the same prefix, the non-yarp projects will install their .ini file in the right directory and yarp will find the required paths. I've been using this for years on my system, and I'm pretty sure that this works, at least for the repositories properly installing stuff.

The problem of that workflow is that it stops working as soon as the user uses its own repo using the robotology-superbuild,only to provide dependencies and installs it in a custom prefix. If the user sets YARP_DATA_DIRS to point to its own prefix, then the path.d is ignored, and all the conf files for all the non-YARP projects in the superbuild are not found (robotology/yarp#336).

[drdanz]

If you want to rely on the XDG_DATA_DIRS variable, the user should set XDG_DATA_DIRS as well. YARP_DATA_DIRS is meant to be in replacement of XDG_DATA_DIRS, not in addition...

[traversaro]

If you want to rely on the XDG_DATA_DIRS variable, the user should set XDG_DATA_DIRS as well. YARP_DATA_DIRS is meant to be in replacement of XDG_DATA_DIRS, not in addition...

Is this possible? According to http://www.yarp.it/git-master/resource_finder_spec.html if I install yarp in <install_prefix> and OtherProject in <other_prefix>, then I can consider both by setting:

YARP_DATA_DIRS=<install_prefix>/share/yarp:<other_prefix>/share/OtherProject

but, as far as I understand, by using XDG_DATA_DIRS I can only add <install_prefix>/share to it so that YARP is found, there is no way to use use XDG_DATA_DIRS so that <other_prefix>/share/OtherProject is considered.

[drdanz]

Right! Which is another reason why supporting this workflow with a different name is a bad idea. I'm not aware of any other framework that allows installing files relative to the framework itself anywhere...