[Bash-completion-devel] [RFC] Completions location

[Ville Skyttä]

On Sunday 20 September 2009, Guillaume Rousse wrote:
> David Paleino a écrit :
> > Hello,
> > I remember we decided to push all completions to respective upstreams,
> > but didn't decide anything more than that, at the time. -- or it could've
> > been a joke of my mind :)
> >
> > On IRC the discussion was raised by the maintainer of the PLD package. He
> > has a few points, which I believe we already discussed about, with some
> > new features:
> >
> > 1) upstreams won't possibly handle completions like we can -- be it
> >    syntactically, stylistically, functionally;

I don't think syntactic or stylistic issues are anything to be concerned 
about.

Regarding functionality, I don't think it would be impossible for upstreams to 
do practically as good job as we (or even better), but we should make it 
easier for them: define a stable well documented API they can count on being 
available and not change.  This would consist of both functions and completion 
snippet dir location stability (perhaps a pkg-config file or something for the 
latter would be a good idea).

When completions are included/installed from upstream packages, there is room 
for improvements that we can't as easily do, which I believe in the long run 
can result in _better_ functionality/performance/end user experience than we 
can provide:

- No need to do any have() or trigger games, when installed with rest of the 
upstream software, it is known that the completed commands are there.

- No need to keep completion stuff for old versions of the software around nor 
try to be careful or do guesses what the commands might look in the future: 
just keep it up to date with the released version - it doesn't have to work 
with anything else except that.  We on the other hand should provide 
documented and stable helpers that work regardless of (supported) bash version 
and to the extent possible, across operating systems.

> > 2) we would lose maintainance of the completions.

Frankly, I think this would be a good trend ;)

> > Or, if we want to keep
> > it, it would be a nightmare: we would need a $vcs write access for the
> > completion for each software package. A mess.

Nah, these should be exceptional cases.  If someone wants to maintain 
something upstream, by all means do it, but there should be no actual 
requirement for this.

> > 3) bash-completion will rapidly decrease in performance, because of
> > probably poorly written code.

I don't buy this.

> For the last issue, which is to distribute in a single package, and
> activate only when needed, I initially attempted to use triggers too.
> However, we now have 175 various completions in contrib directories,
> meaning 175 * 2 triggers (installation/uninstallation) to maintain,
> keeping track of the various mismatch between package names and
> completion file name. All in all, that's just impossible.

This is surely a bit (yep, a bit, not a lot) of work, but why would it be 
impossible?  I haven't packaged post 1.0 bash-completion for Fedora but I do 
for now intend to continue with the trigger approach.  With a few helper 
macros I think it's quite manageable, see 
http://cvs.fedoraproject.org/viewvc/rpms/bash-completion/devel/bash-
completion.spec?revision=1.42&view=markup

> The intent of the script I recently commited in the project
> (install-completions), is to leverage this problem,

I'll however intend to look into this script as well.