tab completion for stack build and exec targets

[ghorn]

I would like to be able to do stack build <tab> and see the build targets like:

$ stack build <tab>
lib1 lib2 lib3

This is something which I'm used to in cabal which I really miss in stack.

Then I'd like to see the executables within each library, like:

$ stack build lib1:<tab>
lib1:exe1 lib1:exe2 lib1:exe3 lib1:exe4

I think the same feature would be useful for stack exec. With cabal I do ./dist/build/<tab>

[mgsloan]

Agreed, this would be very nice to have.

[rubik]

The bash file for Cabal is here
https://github.com/haskell/cabal/blob/master/cabal-install/bash-completion/cabal
and would be very simple to port to Stack. However it relies on the --list-options flag to list all the available commands and options. I don't think Stack has such an option, hasn't it?

[mgsloan]

We actually have bash completion via optparse-applicative: https://github.com/pcapriotti/optparse-applicative/wiki/Bash-Completion

These just need to be extended to have more stack specific smarts, which would be really excellent! I miss having this all the time.

I'm actually rather baffled why this guide recommends passing which exe in. This means that if a different version is on your PATH, you'll still get completions as if it was the old version. As such, I've just installed my completions like this:

mgsloan@computer:/fpco/stack$ sudo -i
root@computer:# /home/mgsloan/.local/bin/stack --bash-completion-script stack > /etc/bash_completion.d/stack

@borsboom Maybe we should document how to install these completions? And maybe our ubuntu package shouldn't use the absolute path to stack for the script? This way if you're using a locally upgraded stack, you will get updated completions.

[borsboom]

Setting up bash completion is documented here:
https://github.com/commercialhaskell/stack/blob/master/doc/shell_autocompletion.md.
But it might make more sense to move this into the install_and_upgrade.md.
It should, at least, be referenced there.

You're probably right about not using the absolute path in the Linux
distribution packages (or recommending it in the docs). Using the absolute
path probably makes sense for most CLI programs, but Stack does seem like
an exception because of the way it can upgrade itself

On Sat, Nov 21, 2015 at 12:29 AM Michael Sloan notifications@github.com
wrote:

We actually have bash completion via optparse-applicative:
https://github.com/pcapriotti/optparse-applicative/wiki/Bash-Completion

I'm actually rather baffled why this guide recommends passing which exe
in. This means that if a different version is on your PATH, you'll still
get completions as if it was the old version. As such, I've just installed
my completions like this:

mgsloan@computer:/fpco/stack$ sudo -i
root@computer:# /home/mgsloan/.local/bin/stack --bash-completion-script
stack > /etc/bash_completion.d/stack

@borsboom https://github.com/borsboom Maybe we should document how to
install these completions? And maybe our ubuntu package shouldn't use the
absolute path to stack for the script? This way if you're using a locally
upgraded stack, you will get updated completions.

—
Reply to this email directly or view it on GitHub
#1343 (comment)
.

[borsboom]

(I've updated the docs and distro package builders to just use stack instead of the absolute path)

[hackeryarn]

I'll give this one a shot since it looks like it's been open for a while and hasn't been picked up.

[mgsloan]

Awesome! :D While I don't want to overload you with complex considerations, it might also be worth considering how this would work with #1748

[hackeryarn]

Absolutely! I was just reading up on optparser-applicative auto complete, and it seems it should work for all those scenarios as well.

[hackeryarn]

It seems that an environment needs to be set before we can fetch the build targets. However, the target actually gets checked when the build command is run. Should I just assume the environment to be local by default for the autocomplete?

This would mean that unless you are in the same directory as your .cabal file, you would not get auto complete.

[mgsloan]

Yeah, that's the primary trickiness of this - we need to load up the configuration and parse the cabal files (since for full target completion we also need to know the compontents of the cabal files).

I'd say it's reasonable to:

• Ignore the possibility of --stack-yaml being specified
• Pay attention to STACK_YAML

Bonus points would be to rely on the cabal file name matching the package name, and only parse it when it looks like the user is trying to complete to a component (e.g. they're asking for completions of pkg:).

[mgsloan]

Implemented!