Add support for command aliases to cabal-install

[sol]

I propose to add support for command aliases to cabal-install. This is inspired by Git's support for aliases; if I have

[alias]
    logk=log --graph --oneline --decorate --all

in ~/.gitconfig, then running git logk will have the same effect as git log --graph --oneline --decorate --all.

Similarly I'd like to have some means to specify that e.g. running cabal fork has the same effect as running cabal get --source-repository.

Git's bash-completion script takes aliases into account, and so should we!

[sol]

I hope that this would also make it easier to find consensus when introducing new commands (see e.g. #2).

[dcoutts]

Interesting idea. If you could cook up a patch, that'd be great.

[sol]

@dcoutts I can look into this eventually. But currently I'm swamped, so not sure when.

Would we want to extend ~/.cabal/config for that, have a separate file ~/.cabal/aliases, or so something directly under ~/? Alias are different from what we currently have in ~/.cabal/config in that they do not change the semantics of cabal, but merely the user interface.

I don't have a strong preference here, but I'm slightly leaning towards ~/.cabal/aliases, as you then can append new alias to the end of the file. This makes a difference when you want to tell someone (e.g. in third-party documentation) how to add an alias. For example:

To make it more convenient, you can add a cabal alias for that:

  echo 'test-extended=test --test-options="--maximum-generated-tests=1000"' >> ~/.cabal/aliases

[23Skidoo]

Another possibility is to add a cabal config command similar to git config:

$ cabal config split-objs
True
$ cabal config split-objs False
$ cabal config split-objs
False

This is harder, but in my opinion preferable to having configuration scattered over several files.

[23Skidoo]

Closing in favour of #3849, which is more recent.