[mr] bash-completion rules

[Adam Spiers]

On Sat, Dec 17, 2011 at 2:14 PM, Antonio Ospite
<ospite at studenti.unina.it> wrote:
> On Sat, 17 Dec 2011 11:58:18 +0000
> Adam Spiers <vcs-home at adamspiers.org> wrote:
>> Unfortunately, in practice this isn't perfect, because (a) a program's
>> upstream maintainer(s) and its completion rule maintainer(s) are often
>> not the same people (e.g. the maintainer of program X may not ever use
>> bash/zsh) and (b) there is no official standard on where an
>> installation should drop a new completion function.
>
> The cost of (a) is, for example, that bash-completion rules are going to
> be copied to the filesystem even if bash itself isn't installed at all.
> FWIW I think I could live with some zsh-related files on my system even
> if I don't use zsh.

Sure, that's a tiny cost, but as I think you already understand, there
is a bigger cost - the risk of having a version of the completion
rules which does not match the version of mr installed.  This is a
common problem; for example on one of my machines, I have a very
recent (developer) version of git which supports `git remote set-url'
but an older version of zsh which does not know how to complete this.
I could upgrade my zsh, but while this may provide something closer to
the correct completion for git, it could make completion worse for
many other commands on my system (e.g. by offering to complete newer
options which are not yet available for the older versions of those
commands which I have installed).

There's also a converse argument.  Completion functions are not only
coupled to the thing they are completing for, but also to the shell's
completion API.  When the API changes, it's better to have completion
functions within the shell's distribution, because the shell's
developers can fix all completion functions to work with the new API
in one go.

The tension between these diametrically opposed considerations
reinforces my previous statement:

>> Therefore in practice, it's up to the distribution packagers to get
>> this right, but their job is made a lot easier if the upstream tarball
>> contains the completion functions, and all they have to do is ensure
>> that the rpm/deb/whatever places that file in the correct location,
>> which ideally would override the completion function shipped with the
>> shell.

because the distribution packagers are the only people who can resolve
these conflicts - after all, the whole point of a distro is to choose
snapshots of versions of thousands of different packages and make sure
they all work together nicely.

It also reinforces my previous recommendation:

>> So my recommendation would be: ship completion rules with mr, but also
>> submit them to the shell project.

> I'd really like to avoid duplication

Normally I'd agree with you 100% (DRY!), but I think this is an
exception, because having completion functions in both the shell
codebases and mr's codebase encourages maintenance by both shell
developers and mr developers.  If mr learns a new option (e.g. the
recent `--force') then the completion functions in the mr repository
will too.  If bash's completion API changes, the bash developers will
update the mr completion function accordingly.  Both types of change
will eventually find their way to the opposite repository.

> I am willing to update mr bash completion rules when needed

But this would mean that every time someone else upgrades their mr
installation, they may also have to upgrade bash, which is really bad.

> but I definitely don't want to communicate
> those changes twice, it's a waste of time.

It's only a waste of time if every distribution out there correctly
packaged the completion function(s) along with mr.  Bundling a
fall-back version with the shell means that even if the distribution
package is missing the completion function(s), at least the user still
gets some completion, even if it is not 100% correct.

> I'd say it's up to the author of mr to decide whether he wants to keep
> this stuff into his codebase or not.

That's very true :-)