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 work vs revisions #770

Closed
kgadek opened this Issue Aug 12, 2015 · 18 comments

Comments

Projects
None yet
6 participants
@kgadek

kgadek commented Aug 12, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Aug 13, 2015

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?

@snoyberg snoyberg added this to the Support milestone Aug 13, 2015

@kgadek

This comment has been minimized.

kgadek commented Aug 13, 2015

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Aug 13, 2015

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

This comment has been minimized.

kgadek commented Aug 14, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Aug 23, 2015

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.

@snoyberg snoyberg closed this Aug 23, 2015

@kgadek

This comment has been minimized.

kgadek commented Oct 14, 2015

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Oct 14, 2015

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

This comment has been minimized.

Contributor

mwu-tow commented Oct 14, 2015

I reported the issue: byorgey/MonadRandom#15

@kgadek

This comment has been minimized.

kgadek commented Oct 14, 2015

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

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Oct 14, 2015

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

This comment has been minimized.

kgadek commented Oct 14, 2015

For future reference: f359cbe

snoyberg added a commit that referenced this issue Oct 15, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Oct 15, 2015

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

@kgadek

This comment has been minimized.

kgadek commented Oct 15, 2015

Difficult to test now that MonadRandom is fixed. As soon as any kind of similar problem will occur, we'll try that. Thank you :)

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Oct 15, 2015

Hopefully next time this happens you won't even notice ;-)

On Thu, Oct 15, 2015, 4:22 PM Konrad notifications@github.com wrote:

Difficult to test now that MonadRandom is fixed. As soon as any kind of
similar problem will occur, we'll try that. Thank you :)


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

@GetContented

This comment has been minimized.

GetContented commented Oct 16, 2015

@snoyberg This works for me now (I installed with git yesterday) and I was getting these errors with the random package.

@mwu-tow

This comment has been minimized.

Contributor

mwu-tow commented Oct 21, 2015

I'm not sure if it works properly.

I'm using stack from master ff45507. When I tried to build a package depending on MonadRandom I got the following:

Continuing despite missing tool: msys2
WARNING: Ignoring out of range dependency (trusting snapshot over Hackage revisions): mtl-2.1.3.1. MonadRandom requires: >=2.2 && <2.3
MonadRandom-0.3.0.2: configure
bifunctors-4.2.1: configure
bifunctors-4.2.1: build
profunctors-4.4.1: configure
profunctors-4.4.1: build
bifunctors-4.2.1: copy/register
profunctors-4.4.1: copy/register
Progress: 3/12
--  While building package MonadRandom-0.3.0.2 using:
      C:\s\setup-exe-cache\setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.8.4.exe --builddir=.stack-work\dist\d96ab9d9\ configure --with-ghc=C:\Users\mwurb_000\AppData\Local\Programs\stack\x86_64-windows\ghc-7.8.4\bin\ghc.exe --with-ghc-pkg=C:\Users\mwurb_000\AppData\Local\Programs\stack\x86_64-windows\ghc-7.8.4\bin\ghc-pkg.exe --user --package-db=clear --package-db=global --package-db=C:\s\snapshots\819afc54\pkgdb\ --libdir=C:\s\snapshots\819afc54\lib --bindir=C:\s\snapshots\819afc54\bin --datadir=C:\s\snapshots\819afc54\share --libexecdir=C:\s\snapshots\819afc54\libexec --sysconfdir=C:\s\snapshots\819afc54\etc --docdir=C:\s\snapshots\819afc54\doc\MonadRandom-0.3.0.2 --htmldir=C:\s\snapshots\819afc54\doc\MonadRandom-0.3.0.2 --haddockdir=C:\s\snapshots\819afc54\doc\MonadRandom-0.3.0.2 --dependency=base=base-4.7.0.2-b10419535963bafa416c2ecaab830bcf --dependency=mtl=mtl-2.1.3.1-760198d97546aac7338b4b28eb6a06eb --dependency=random=random-1.1-d4b25193af78e8e7de14950494fa2161 --dependency=transformers=transformers-0.3.0.0-5706042946254d1f2637b20fb7e9675d --dependency=transformers-compat=transformers-compat-0.4.0.3-8edfead5dedb513d6a8253cc3f34f54c
    Process exited with code: ExitFailure 1
    Logs have been written to: H:\z\build\.stack-work\logs\MonadRandom-0.3.0.2.log

    Configuring MonadRandom-0.3.0.2...
    setup-Simple-Cabal-1.22.4.0-x86_64-windows-ghc-7.8.4.exe: At least the
    following dependencies are missing:
    mtl >=2.2 && <2.3 && ==2.1.3.1

Making stack update magically solved the issue. However, it seems to be fixed rather by the MonadRandom update that removed problematic constraint rather than by stack.
Still, I'm not sure if it is actually the case — just thought it might be good to report this.

@janpath

This comment has been minimized.

janpath commented May 31, 2018

Here is another example where the patch doesn't work (Stack version 1.7.1):

$ stack --resolver lts-3.22 build semigroupoids
WARNING: Ignoring out of range dependency (trusting snapshot over Hackage revisions): tagged-0.8.2. semigroupoids requires: >=0.8.5 && <1
semigroupoids-5.0.0.4: configure

--  While building custom Setup.hs for package semigroupoids-5.0.0.4 using:
      /tmp/stack19996/semigroupoids-5.0.0.4/.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.4.0/setup/setup --builddir=.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.4.0 configure --with-ghc=/home/jan/.stack/programs/x86_64-linux/ghc-nopie-7.10.2/bin/ghc --with-ghc-pkg=/home/jan/.stack/programs/x86_64-linux/ghc-nopie-7.10.2/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/home/jan/.stack/snapshots/x86_64-linux-nopie/lts-3.22/7.10.2/pkgdb --libdir=/home/jan/.stack/snapshots/x86_64-linux-nopie/lts-3.22/7.10.2/lib --bindir=/home/jan/.stack/snapshots/x86_64-linux-nopie/lts-3.22/7.10.2/bin --datadir=/home/jan/.stack/snapshots/x86_64-linux-nopie/lts-3.22/7.10.2/share --libexecdir=/home/jan/.stack/snapshots/x86_64-linux-nopie/lts-3.22/7.10.2/libexec --sysconfdir=/home/jan/.stack/snapshots/x86_64-linux-nopie/lts-3.22/7.10.2/etc --docdir=/home/jan/.stack/snapshots/x86_64-linux-nopie/lts-3.22/7.10.2/doc/semigroupoids-5.0.0.4 --htmldir=/home/jan/.stack/snapshots/x86_64-linux-nopie/lts-3.22/7.10.2/doc/semigroupoids-5.0.0.4 --haddockdir=/home/jan/.stack/snapshots/x86_64-linux-nopie/lts-3.22/7.10.2/doc/semigroupoids-5.0.0.4 --dependency=base=base-4.8.1.0-4f7206fd964c629946bb89db72c80011 --dependency=base-orphans=base-orphans-0.4.5-61f87fbe40b70a96b4f01742198bd89e --dependency=bifunctors=bifunctors-5-64a68cd686e3ed3081716860a5c9f269 --dependency=comonad=comonad-4.2.7.2-b2f21851236b3131b29ff7c8a3538a5b --dependency=containers=containers-0.5.6.2-2de75421d746ab474b330e43191bb31b --dependency=contravariant=contravariant-1.3.3-c23cba03467c0137d5cf24a5c0d60a8f --dependency=distributive=distributive-0.4.4-474748c5a9ad68023cbbe5ca63546d1c --dependency=semigroups=semigroups-0.16.2.2-f9a9e03c02d4e53e32eea6fce3eebad6 --dependency=tagged=tagged-0.8.2-26b0adcd0fe1ee6463064939496bf1cc --dependency=transformers=transformers-0.4.2.0-21dcbf13c43f5d8cf6a1f54dee6c5bff --dependency=transformers-compat=transformers-compat-0.4.0.4-3ca5cbcec233c17da785d5f27705643c
    Process exited with code: ExitFailure 1
    Logs have been written to: /home/jan/.stack/global-project/.stack-work/logs/semigroupoids-5.0.0.4.log

    [1 of 2] Compiling Main             ( /tmp/stack19996/semigroupoids-5.0.0.4/Setup.lhs, /tmp/stack19996/semigroupoids-5.0.0.4/.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.4.0/setup/Main.o )
    [2 of 2] Compiling StackSetupShim   ( /home/jan/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack19996/semigroupoids-5.0.0.4/.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.4.0/setup/StackSetupShim.o )
    Linking /tmp/stack19996/semigroupoids-5.0.0.4/.stack-work/dist/x86_64-linux-nopie/Cabal-1.22.4.0/setup/setup ...
    Configuring semigroupoids-5.0.0.4...
    setup: At least the following dependencies are missing:
    tagged >=0.8.5 && <1 && ==0.8.2

The problem seems to be, that while the above patch makes stack accept the out of range dependency it doesn't make cabal do so too. So cabal fails when it encounters the contradictory dependency bound tagged >= 0.8.5 && <1 && ==0.8.2.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Jun 11, 2018

@janpath Ah, yes, this probably means that stack now needs to pass --exact-configuration into the configure invocation.

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