Plugin support with git-style "fall-through" of the executable call

[yamadapc]

So with git, if I have say a binary git-branch-fzf on my PATH and type git branch-fzf, it'll call my binary.

This is a nice way of providing some extension to the tool and I'd like if stack did it. Potentially it could give precedence to the outside binary, so that people could write experimental wrappers over built-in commands.

Why I think this matters:

• Being extensible is nice, this is an easy way of letting other developers add new commands or extend existing ones
• It's not enough to let people modify the stack project and ask users to rebuild it, because there's much more friction in doing this
• Good things come out of people experimenting with things and it's easier to write software when there's user feedback (at least for me)

Seems like it's pretty easy, not sure if it's wanted (maybe it's even already supported somehow).

[borsboom]

This is something we had early on and then removed because it was causing bad startup times and problems when Docker integration was enabled, and didn't seem worth putting a lot of effort into solving at the time. We'd welcome a PR resurrecting it as long as those two problems are resolved.

[yamadapc]

Do you think it's better to give precedence to stack commands or binaries?

[yamadapc]

Okay, just looked at how git does it and it seems it prefers internal commands. I think I remember stack being split onto several modules. I guess it was dropped because of multiple runtimes being slower? This would be just ignored here, I guess. My idea was:

• See if arguments run a command on stack
• If it doesn't instead of printing "Invalid argument yadayada'" look in thePATH` for a matching binary
• Execute it or current action

[borsboom]

That sounds good to me. Probably as a first phase, don't do anything special for Docker integration (plugins will just run on the host, even in Docker-enabled projects). In a separate phase, we can look at providing an easy-to-use but flexible way for plugins to re-launch themselves in a Docker container the same way stack does (until then, a plugin can always use stack exec to run specific commands in Docker)

[yamadapc]

Will readProcessWithExitCode "which" [executable] work on windows?

[yamadapc]

Initial implementation is there ^^
Two things:

• Doing this on Options.Applicative.Complicated.complicatedOptions is a bit ugly
• I don't know if it'll work on Windows

It's probably an useful package NPM has which (which is like which :D) and npm-which (which also includes npm installed binaries). This is nice because npm-which could be like cabal-which or stack-which and try to look for locally installed executables regardless of the PATH. That could be useful for scripting. Of course, I'm not sure what's your policy on adding dependencies.

[borsboom]

No, but take a look at `findExecutable` in System/Process/Read.hs.

[yamadapc]

Coolness; replaced it with System.Directory.findExecutable.

[borsboom]

Please make a pull request for your branch; it makes discussing the code a bit easier.

I agree having all of that in complicatedOptions is a bit ugly; I'd prefer if more of this logic is moved into Main.