CODEWITHSUNDEEP
haskellcabal
d8d0d65b3f7cf42
d8d0d65b3f7cf42

Reputation: 2653

cabal hell with dependencies of ghc-baked in packages

I have the following instance of cabal hell:

(with ghc-7.8.3 built from source on x86_64 GNU/Linux, and user-install: True in .cabal/config)

1) at some time, transformers-0.4.0.0 was installed (in user space, shadowing (?) transformers-0.3 from the global space)

2) later, several libraries pick transformers-0.4

3) then, I install hint, which depends on ghc, which depends on transformers-0.3, and which cannot be changed, since ghc is hard-wired.

result: I cannot use libraries from 2) and hint in one project.

As a work-around, I am putting constraint: transformers installed in .cabal/config, and rebuild. Is there a better way to handle this situation - or to avoid it in the first place?

Upvotes: 6

Views: 224

Answers (1)

Joachim Breitner
Joachim Breitner

Reputation: 25763

Is there a better way to handle this situation.

No, your approach is sensible.

or to avoid it in the first place?

Tricky. Most people do not build stuff depending on ghc, so for them it makes sense to upgrade transformers etc. Therefore, your constraint is not a suitable default.

As Zeta writes: Sandboxes can help. If you had used sandboxes for your installations in (2), and used another sandbox for whatever tries to use both hint and (2), then it would simply build these dependencies dedicated for whatever you are building.

This comes at the expense of not sharing any space or build-time between the various things you are doing.

Upvotes: 4

Related Questions