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

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

Stack work vs revisions #770

kgadek opened this issue Aug 12, 2015 · 18 comments
Milestone

Comments

@kgadek
Copy link

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

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

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

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

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

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

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

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

mwu-tow commented Oct 14, 2015

I reported the issue: byorgey/MonadRandom#15

@kgadek
Copy link
Author

kgadek commented Oct 14, 2015

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

@snoyberg
Copy link
Contributor

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

kgadek commented Oct 14, 2015

For future reference: f359cbe

@snoyberg
Copy link
Contributor

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

@kgadek
Copy link
Author

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

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

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

@mwu-tow
Copy link
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.

@juliapath
Copy link

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

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants