cabal hell with dependencies of ghc-baked in packages

Question

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?

Answer 1

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.