stack shouldn't recommend adding extra-deps to your global stack.yaml, or recommend `stack solver`, when run outside a project

[radix]

Someone came on IRC and explained their problems when trying to install lambdabot. They ran stack install lambdabot, outside of any stack/haskell project, and stack couldn't install it because of dependency issues. The problem is that stack recommended that they edit their C:\Users\XXX\AppData\Roaming\stack\global\stack.yaml file and add extra-deps, which is a very bad idea.

In addition, it suggested using stack solver, which is also pointless because they weren't in a stack/haskell project directory.

Perhaps stack install should take --extra-deps arguments for these situations?

[mgsloan]

Thanks for the report. It's good to know what issues people are running into. See #1693 for a discussion of what we should probably do about this. Closing as a duplicate of that, and addressing the other parts of the issue.

While the magic in #1693 will be good, it's almost good to run into issues like this. Otherwise, people might not learn how stack works. The global project is special in almost no ways except that it's a default when there's nothing else to use.

The problem is that stack recommended that they edit their C:\Users\XXX\AppData\Roaming\stack\global\stack.yaml file and add extra-deps, which is a very bad idea.

That's actually a fine idea, what's wrong with it? A better suggestion would probably be to start a new stack.yaml. We could add such messaging. Might be worthwhile if we don't get around to implementing #1693 for the current version.

In addition, it suggested using stack solver, which is also pointless because they weren't in a stack/haskell project directory.

There isn't really anything wrong with doing that, as long as you understand it will affect future uses of the global project.

[mgsloan]

Eh, I guess I'll leave it open as a reminder to make the messaging better incase we don't do #1693

[sjakobi]

In addition, it suggested using stack solver, which is also pointless because they weren't in a stack/haskell project directory.

There isn't really anything wrong with doing that, as long as you understand it will affect future uses of the global project.

stack solver's behaviour can be quite surprising depending on the current working directory:

~ $ stack solver
Run from outside a project, using implicit global project config
Using resolver: lts-5.11 from implicit global project's config file: /home/simon/.stack/global-project/stack.yaml
Using configuration file: .stack/global-project/stack.yaml
/home/simon/src/tinc/tinc.cabal is up-to-date
/home/simon/src/hpack/hpack.cabal is up-to-date
^Cuser interrupt
...

I guess stack solver just shouldn't go looking for project packages when it's using the global project config.

[mgsloan]

I guess we could special case the global project for solver. I'd like to keep the global project behavior essentially identical with norms projects, as it is now. His keeps things conceptually simple while potentially being surprising to those who think something else is happening (something more apt-get ish or cabal installish)

How about just adding a "--global" flag which opts on to modifying the global project? So it'd be an error to try to run it on the global project unless the flag is specified. I think it'd be ok to add special enabling flags and messaging for the global project. But otherwise it should just be a plain project.

[mgsloan]

Closing in favor of #2656