Skip to content
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

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

Closed
radix opened this issue Apr 17, 2016 · 7 comments

Comments

@radix
Copy link
Contributor

radix commented Apr 17, 2016

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
Copy link
Contributor

mgsloan commented Apr 18, 2016

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
Copy link
Contributor

mgsloan commented Apr 18, 2016

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

@sjakobi
Copy link
Member

sjakobi commented Apr 19, 2016

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
Copy link
Contributor

mgsloan commented Apr 19, 2016

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
Copy link
Contributor

mgsloan commented Oct 1, 2016

Closing in favor of #2656

@mgsloan mgsloan closed this as completed Oct 1, 2016
@misterbeebee
Copy link

#2656 was closed due to solver being removed, but the original motivation for this issue still remains: "stack shouldn't recommend adding extra-deps to your global stack.yaml" when installing lambdabot

Should this issue be re-opened?

Details:

$ stack install lambdabot-haskell-plugins

Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for lambdabot-haskell-plugins-5.2:
    IOSpec must match >=0.2, but the stack configuration has no specified version  (latest matching version is 0.3.1.1)
 [...]

needed since lambdabot-haskell-plugins is a build target.

Some different approaches to resolving this:

  * Recommended action: try adding the following to your extra-deps in [$HOME]/.stack/global-project/stack.yaml:

[list of package versions]

@misterbeebee
Copy link

@mgsloan's earlier comment "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." seems still relevant due to the disappearance of solver.

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

No branches or pull requests

4 participants