Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Stack shouldn't try and use a 8.0.1 resolver when the base bound is for an older version. #2502
Thanks for the ticket. But while the output is a bit confusing, stack's heuristics still end up with sensible guesses. The bigger problem is that after
Regarding the original report, below's an analysis, but I'm more interested in the parsing errors above.
To summarize, that package says
AFAICS it even tries a few sensible resolvers which fail for other reasons:
I agreed it could be nice to be smarter. (And maybe this should even be priority 2).
Making it perfect might be nontrivial, but this would be a heuristic enhancement so we can focus on typical constraints. We'd need a mapping from base major versions to GHC versions (e.g. 4.8->7.10), which is easy enough to hardcode for the supported versions assuming simple constraints—though we probably should have it in some external DB.
However, that might be overkill, since the info is in the snapshots themselves. We already detect incompatible resolvers (and explain the conflict); we might want to hide failures when base doesn't match.
According to the conversation, what
But I've tried this locally and stack came up with a plan! Looking more closely at the source, the problem might be Windows-specific, but not due to
Below's what I get on OS X—basically, a config based on
resolver: lts-5.18 packages: - '.' # Dependency packages to be pulled from upstream that are not in the resolver # (e.g., acme-missiles-0.3) extra-deps: - conduit-extra-22.214.171.124 - http-client-0.5.1 - http-client-tls-0.3.0 - http-conduit-2.2.0
The log of
Noticed on #2502. Basically, `isSuffixOf "suffix" "stuff suffix\r"` is spuriously false, so we should better strip `\r`. I've not yet verified that `\r` is actually there; I infer it from the presence of `stripCR` and the parse failure. Time to test this.
As shown in #2502, `cabal init --solver` can fail with `Could not parse cabal-install errors` on Windows. The problem boils down to the fact that we test `isSuffixOf "suffix" "stuff suffix\r"`, which is false, so we should better strip `\r` before calling `isSuffixOf`. I've verified that `\r` is actually there only indirectly; I inferred it from the presence of `stripCR` and the parse failure, and I've recently seen the behavior of lines on strings with Windows line ends. Testing confirms this PR fixes the bug—the original procedure fails with the parent commit and works with this one.
Regarding the original request, stack in fact figures the GHC mismatch and says:
The only annoyance is that it must download the build plan, and that's slow the first time, but it's cached afterwards.
The underlying other bug is fixed in #2508.