New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
yamadapc opened this Issue Nov 26, 2015 · 9 comments

Comments

Projects
None yet
2 participants
@yamadapc
Contributor

yamadapc commented Nov 26, 2015

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 comment has been minimized.

Contributor

borsboom commented Nov 26, 2015

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.

@borsboom borsboom added this to the P3: Optional milestone Nov 26, 2015

@yamadapc

This comment has been minimized.

Contributor

yamadapc commented Nov 26, 2015

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

@yamadapc

This comment has been minimized.

Contributor

yamadapc commented Nov 26, 2015

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

This comment has been minimized.

Contributor

borsboom commented Nov 26, 2015

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

This comment has been minimized.

Contributor

yamadapc commented Nov 26, 2015

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

@yamadapc

This comment has been minimized.

Contributor

yamadapc commented Nov 26, 2015

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

This comment has been minimized.

Contributor

borsboom commented Nov 26, 2015

@yamadapc

This comment has been minimized.

Contributor

yamadapc commented Nov 26, 2015

Coolness; replaced it with System.Directory.findExecutable.

@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 26, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment