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

Revision of semigroupoids-5.0.0.4 broke lts-3.x #3185

Closed
unclechu opened this issue Jan 9, 2018 · 15 comments
Closed

Revision of semigroupoids-5.0.0.4 broke lts-3.x #3185

unclechu opened this issue Jan 9, 2018 · 15 comments

Comments

@unclechu
Copy link
Contributor

unclechu commented Jan 9, 2018

Revision have been made 6 January:
https://hackage.haskell.org/package/semigroupoids-5.0.0.4/revisions/

Even latest lts-3.22 have tagged-0.8.2 but minimal acceptable version in new revision is 0.8.5, so, build that depends on lts-3.12 fails with this error:

Error: While constructing the build plan, the following exceptions were encountered:
In the dependencies for semigroupoids-5.0.0.4:
    tagged-0.8.1 from stack configuration does not match >=0.8.5 && <1 (latest matching version is 0.8.5)
needed due to %OUR_PACKAGE_NAME%-1.0 -> semigroupoids-5.0.0.4
Some potential ways to resolve this:
  * Recommended action: try adding the following to your extra-deps in /foo/bar/baz/stack.yaml:
- tagged-0.8.5
  * Set 'allow-newer: true' to ignore all version constraints and build anyway.
  * You may also want to try using the 'stack solver' command.
Plan construction failed.

Is there any solution to use original revisions to prevent this mess?

@unclechu
Copy link
Contributor Author

unclechu commented Jan 9, 2018

@RyanGlScott Maybe you could provide some more information?

@dzhus
Copy link
Contributor

dzhus commented Jan 9, 2018

In the grand scheme of things, is this a Stackage issue («due to revisions, snapshots are not really snapshots») or a Hackage issue («tightening of lower bounds is allowed and one can do something other than https://github.com/haskell-infra/hackage-trustees/blob/master/cookbook.md#best-practice-for-managing-meta-data »)?

@kadoban
Copy link

kadoban commented Jan 9, 2018

@dzhus:

https://github.com/haskell-infra/hackage-trustees/blob/master/revisions-information.md seems to suggest that you can do whatever you want to bounds on dependencies via revisions.

So, assuming revisions exist and they aren't going anywhere (which seems like a good assumption), it must be something that has to be dealt with by stackage or by stack. Any package author being able to break any old snapshot at any time doesn't sound good.

p.s. I'm assuming this bug report is accurate, it looks like it is but I didn't actually try it myself yet.

@gbaz
Copy link
Contributor

gbaz commented Jan 10, 2018

relevant: ekmett/semigroupoids#62

@kadoban
Copy link

kadoban commented Jan 10, 2018

@unclechu: I can't seem to replicate this. Can you give more information about what you did to get that error? Also what is your version of stack? I'm on v1.6.3

I tried creating a new stack project, setting the resolver to lts-3.22 and adding the semigroupoids package as a dependency. It appears to build fine with no warning or error.

It's possible I screwed something up, but I'm not seeing what.

@mgsloan
Copy link
Contributor

mgsloan commented Jan 10, 2018

Any lts-6 and onward, and nightlies roughly around 2016-05-25 and onward all specify hackage revisions, so that they are not affected by these mutations to cabal metadata.

@kadoban I can reproduce it by running stack build --resolver lts-3.22 semigroupoids.

We should consider a stack modification that makes older snapshots more reliable. Perhaps by matching revisions by the latest revision at the time of the snapshot release. Hopefully revisions come with date info.

@kadoban
Copy link

kadoban commented Jan 10, 2018

@mgsloan That's odd, I tried that too and couldn't reproduce with that command either.

@mgsloan
Copy link
Contributor

mgsloan commented Jan 10, 2018

Huh! You might already have that semigroupoids built, or some other form of caching. Curious!

@unclechu
Copy link
Contributor Author

@kadoban Maybe something is cached? I also couldn't reproduce it in CI builds until I remove cache of .stack.

@kadoban
Copy link

kadoban commented Jan 10, 2018

Oh, that's interesting. Maybe I already had 'tagged' built or something? I noticed it did actually build semigroupoids when I tried, so I figured that was enough, but I didn't consider any caching beyond that really. I'll try later with a clean .stack and etc.

@jberryman
Copy link

I think my experience meshes with @unclechu . We ran into this same issue (with semigroupoids revision bump), which only manifested on CI. Could not repro locally after a stack clean --full && stack update. We only fixed the dependency and made sure the build worked on CI, but didn't try to understand the issue further.

@unclechu
Copy link
Contributor Author

@jberryman stack clean --full removes just .stack-work of a current project, but look also for ~/.stack. You could try to build with overwritten $HOME, like this:

$ env HOME=/tmp/foobar stack build

@unclechu
Copy link
Contributor Author

@unclechu
Copy link
Contributor Author

I found a temporary solution, I just added explicit revision of semigroups package to extra-deps: section of stack.yaml: - semigroupoids-5.0.0.4@rev:0 (but also realized that explicit revision isn't working for stack 1.4.0 but working with 1.6.3, not sure in which stack version this feature was invented).

@unclechu
Copy link
Contributor Author

Thanks to @snoyberg for the hint in his PR so I can solve it right now.

banacorn added a commit to banacorn/json-rpc that referenced this issue May 19, 2018
Got this error when building the project:
```
Configuring semigroupoids-5.0.1...
setup: At least the following dependencies are missing:
tagged >=0.8.5 && <1 && ==0.8.3
```

This was caused by a revision done to some old Stackage releases:
ekmett/semigroupoids#71
commercialhaskell/stackage#3185

It is fixed by relaxing the dependency constraints a bit as suggested
by @ekmett.
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