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

Solver happy but no build plan #1150

Closed
magthe opened this issue Oct 12, 2015 · 7 comments
Closed

Solver happy but no build plan #1150

magthe opened this issue Oct 12, 2015 · 7 comments

Comments

@magthe
Copy link

magthe commented Oct 12, 2015

I recently tried to get some elm stuff building. This is what I did:

% stack unpack elm-{compiler,make,package,reactor,repl}
% stack init --resolver lts-2

Then I ran stack solver until it was happy. I ended up with this

flags: {}
packages:
- elm-reactor-0.3.1/
- elm-compiler-0.15/
- elm-package-0.5/
- elm-repl-0.4.1/
- elm-make-0.1.2/
system-ghc: false
extra-deps:
- blaze-builder-0.3.3.4
- blaze-html-0.7.1.0
- blaze-markup-0.6.3.0
- optparse-applicative-0.10.0
- transformers-compat-0.3.3.3
- websockets-snap-0.9.2.0
resolver: lts-2.22

This results in

% stack solver
This command is not guaranteed to give you a perfect build plan
It's possible that even with the changes generated below, you will still need to do some manual tweaking
Asking cabal to calculate a build plan, please wait
No needed changes found

To automatically modify your stack.yaml file, rerun with '--modify-stack-yaml'

However, stack build is not so happy:

There were multiple candidates for the Cabal entry "Main.hs(/home/lmagnus/tmp/elm-lang2/elm-repl-0.4.1/src/Main.hs), picking /home/lmagnus/tmp/elm-lang2/elm-repl-0.4.1/tests/Main.hs
While constructing the BuildPlan the following exceptions were encountered:

--  Failure when adding dependencies:    
      blaze-builder: needed (>=0.4 && <0.5), 0.3.3.4 found (latest is 0.4.0.1)
    needed for package: blaze-builder-enumerator-0.2.1.0

--  Failure when adding dependencies:    
      snap-core: needed (-any), couldn't resolve its dependencies
      snap-server: needed (-any), couldn't resolve its dependencies
      websockets-snap: needed (>=0.8.2.1), couldn't resolve its dependencies
    needed for package: elm-reactor-0.3.1

--  Failure when adding dependencies:    
      blaze-builder-enumerator: needed (>=0.2 && <0.3), couldn't resolve its dependencies
    needed for package: snap-core-0.9.7.2

--  Failure when adding dependencies:    
      blaze-builder-enumerator: needed (>=0.2.0 && <0.3), couldn't resolve its dependencies
      snap-core: needed (>=0.9.3 && <0.10), couldn't resolve its dependencies
    needed for package: snap-server-0.9.5.1

--  Failure when adding dependencies:    
      snap-core: needed (>=0.8 && <0.10), couldn't resolve its dependencies
      snap-server: needed (>=0.8 && <0.10), couldn't resolve its dependencies
    needed for package: websockets-snap-0.9.2.0

I did expect that making stack solver happy would result in usable build plan

@snoyberg
Copy link
Contributor

I haven't been able to look into this in detail yet, but stack solver wasn't intended to provide guidance on how to override a snapshot package. The standard workflow would be closer to:

$ stack init --resolver ghc-7.8
$ stack solver

@magthe
Copy link
Author

magthe commented Oct 12, 2015

Yes, that's what I ended up doing in order to get the build through.

@snoyberg
Copy link
Contributor

Problem determined: solver is currently ignoring changes in flags when the package version remains the same.

@magthe
Copy link
Author

magthe commented Oct 13, 2015

Aha, yes, that would explain it. So then you have a test case for when you get around to fixing it :)

@harendra-kumar
Copy link
Collaborator

PR #1583 should fix the problems discussed here and more. With that change solver detects the flag changes and also it uses a snapshot resolver with only required extra dependencies on top of that. It should now always give you a good plan when it succeeds and if it doesn't that is a bug.

@borsboom
Copy link
Contributor

@magthe Now that PR #1583 is merged, does that resolve this issue?

@magthe
Copy link
Author

magthe commented Feb 8, 2016

@borsboom Yes, go ahead and close it :)

@mgsloan mgsloan closed this as completed Feb 8, 2016
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

5 participants