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

packages affected by inaccurate conduit related bounds #125

Closed
hvr opened this issue Jan 17, 2018 · 6 comments
Closed

packages affected by inaccurate conduit related bounds #125

hvr opened this issue Jan 17, 2018 · 6 comments

Comments

@hvr
Copy link
Contributor

hvr commented Jan 17, 2018

@ndmitchell
Copy link

I've manually revised Hoogle 5.. Happy to revise Hoogle 4. if anyone wants and can give me the error (my guess is the matrix builder will do so shortly).

As a matter of course, perhaps you should @ndmitchell when raising issues about my packages, and similarly for everyone else? Otherwise there's a non-zero chance I would have missed this.

@RyanGlScott
Copy link

Perhaps snoyberg/conduit#353 also falls under this?

I've worked around this manually in haskell/criterion@bd5898b by adding a resourcet >= 1.1.11 bound. I'm not sure when what versions of resourcet that conduit-1.2.13 doesn't build with, but I do know that:

  • It's broken with resourcet-1.1.3.3
  • It works with resourcet-1.1.11

@ndmitchell
Copy link

@RyanGlScott - it's also not clear why Cabal deliberately picks quite an old version of resourcet. Is there something weird that's causing it to go there?

@hvr
Copy link
Contributor Author

hvr commented Feb 26, 2018

@ndmitchell Most likely because it tries to optimise for the freshness of some other package (I suspect for exception-0.9), which forces it to compromise on resourcet; in general this isn't an optimization problem with a clear optimal solution / criteria to optimise for. And this wouldn't be a problem anyway if conduit's dependency specification had accurate lower bounds.

@phadej
Copy link
Member

phadej commented Feb 26, 2018

http://hackage.haskell.org/package/resourcet-1.1.3.3 is the last version not depending on transformers-compat. Every other newer resourcet-1.1 version depends on transformers-compat <0.6 (or <0.5).

Solver choses that it's better to pick transformers-compat-0.6 than resourcet-1.1.11 for install plan.

diff between non-restricted, and --constraint=resourcet>=1.1.11 plans. One could say these install plans aren't comparable (in partial order sense), cannot say which one is "better".

--- first.txt	2018-02-26 21:35:03.100530713 +0200
+++ second.txt	2018-02-26 21:35:32.128872790 +0200
@@ -32,7 +32,8 @@
 js-flot-0.8.3
 critbit-0.2.0.0
 conduit-1.2.13
-resourcet-1.1.3.3
+resourcet-1.1.11
+unliftio-core-0.1.1.0
 mmorph-1.1.1
 lifted-base-0.2.3.11
 monad-control-1.0.2.3
@@ -75,8 +76,7 @@
 semigroups-0.18.4
 unordered-containers-0.2.9.0
 tagged-0.8.5
-transformers-compat-0.6.0.4
-generic-deriving-1.12.1
+transformers-compat-0.5.1.4
 transformers-0.4.2.0
 template-haskell-2.10.0.0
 pretty-1.1.2.0

@andreasabel
Copy link
Contributor

The OP seems fixed and the issue has been inactive for > 3 years.
Closing. Welcome to reopen with a TODO list if there is interest.

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

No branches or pull requests

5 participants