You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
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).
The text was updated successfully, but these errors were encountered:
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.
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
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)
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.