Development tools option

[Pitometsu]

It's a feature request.
As I understood, in case when I need some local development tool, e.g. intero, I should make next steps:

cd project
stack update
stack build
stack install intero ghc-mod etc

Would it be reasonable to make this step more declarative and add field with packages list which just install with same resolver?
Like

tools: intero ghc-mod etc

And something like

stack install-tools

[sjakobi]

Can you explain the advantage of keeping a list of these tools in the stack configuration as opposed to having a short script that executes these steps?

Also, would you define these tools in your global config (~/.stack/config.yaml) or in the project stack.yaml?

I believe you can already build project-local tools by defining them in the extra-deps but that might not be the best UI for the purpose.

[Pitometsu]

extra-deps is a wrong bad way to do it, also it may just break things. Tools are not dependencies and can have incompatible with main project own dependencies.
Maybe right way will be put tools list per poroject, but not in stack.yaml, which used for building project, but in additional separate yaml file.
Why not script? Well, in general all things may be implemented this way, even stack. But declarative way easy to manage for developers. It may be one known common place for such thinks in any stack project.

[sjakobi]

extra-deps is a wrong bad way to do it, also it may just break things. Tools are not dependencies and can have incompatible with main project own dependencies.

I agree.

Maybe right way will be put tools list per poroject, but not in stack.yaml, which used for building project, but in additional separate yaml file.

In general, I'd prefer that stack need as few configuration files as possible. There has been the idea of adding a stack.local.yaml that would allow a developer to override a stack.yaml that they share with other developers, but that's a slightly different idea.

Given that development tools are something personal that may differ between different developers on a team, I'm not sure that the project configuration is the right place for this. But keeping them in the global config (~/.stack/config.yaml) might make sense. For example I might extend my config.yaml with

tools:
- intero
- hlint
- hindent

and run stack setup --install-tools in a project to get them set up.

Opinions, @chrisdone, @mgsloan, @borsboom?

[Pitometsu]

But global config may have different resolver which may be significant in some cases.
I like idea about stack.local.yaml. In this case tools: for project may be used e. g. for building tools/CI tools/deployment haskell-only (from stack) tools. Any additional haskell packages that we need to have with same resolver.

[Pitometsu]

Oh, I missed your idea: well, user can have tools list in global config, but install it per-project, right?
In this case it usable, I agree.

[sjakobi]

But global config may have different resolver which can be significant in some cases.

You mean the "(implicit) global project" here, e.g. ~/.stack/global-project/stack.yaml, right?
The relationship between the global (non-project) configuration in ~/.stack/config.yaml and the global project is the same as between the global config and any other project.

I'll wait for more feedback from others at this point.

[Fabs]

I got here trying to solve the same problem. How do I handle dev dependencies, e.g: apply-refact hlint stylish-haskell hasktags hoogle per project?

Did something emerge to solve that use-case since you folks last talked here?

[snoyberg]

The flag --copy-compiler-tool was added to address (what I think is) the use case described here. There's also the build-tools-depend field in cabal files. Closing in favor of those two features.