Stack work vs revisions

[kgadek]

Coming from #337 , we set resolver: ghc-7.10 and specify dependencies in extra-deps.

We had PR'd Kmett's nats to relax upper-bound from base < 4.8 so it would work with GHC 7.10. It's probably worth seeing: ekmett/nats#10 (comment)

Note: It is very likely that you'll run into more issues of this sort if stack isn't capable of disambiguating dependencies by compiler version.

Anyway.

The issue here is that stack doesn't appear to support revisions (x-revision in .cabal file). How would one specify that want package X.Y.Z revision N?

[snoyberg]

Huh, it looks like my previous message didn't go through.

stack definitely does support revisions from Hackage. Perhaps you need to run stack update to download the latest revisions?

[kgadek]

What would I need to do if I wanted to have nats-1 in initial revision 0 as opposed to revision 1?

[snoyberg]

That's not supported, but I'm not sure why you'd want to do that.

On Thu, Aug 13, 2015, 6:08 PM Konrad notifications@github.com wrote:

What would I need to do if I wanted to have nats-1 in initial revision 0
as opposed to revision 1?

—
Reply to this email directly or view it on GitHub
#770 (comment)
.

[kgadek]

I imagine a scenario where latest revision changes dependencies in a way that breaks builds, so one would like a previous version.

That's not a common use-case though.

[snoyberg]

I don't think stack should make any change here: it's properly reflecting the way upstream Hackage is working. We can question the wisdom of this approach by Hackage (I have in the past), but nonetheless that's the situation we're in.

[kgadek]

@snoyberg I believe revision 1 of MonadRandom-0.3.0.2 broke LTS-2.22. What can be done to fix this?

[snoyberg]

I'd report it to Brent, if the build was working previously, this change is
a mistake.

On Wed, Oct 14, 2015, 4:30 PM Konrad notifications@github.com wrote:

@snoyberg https://github.com/snoyberg I believe
https://hackage.haskell.org/package/MonadRandom-0.3.0.2/revisions/ broke
LTS-2.22. What can be done to fix this?

—
Reply to this email directly or view it on GitHub
#770 (comment)
.

[mwu-tow]

I reported the issue: byorgey/MonadRandom#15

[kgadek]

Meantime, what can be done to mitigate such problems in the future?

[snoyberg]

The problem's been fixed upstream. For future occurrences: I've added an allow-newer config option to master, which will ignore these kinds of situations.

[kgadek]

For future reference: f359cbe

[snoyberg]

Actually, if you could also test out df54339 (without using --allow-newer), I'd appreciate it.