The latest cabal-install that I’ve been using (0.13.3, from the darcs repo) is nice; it lets you know when you might break your GHC installation with reinstalls. What I want to know is this: suppose a cabal install foo would perform a reinstall that would break my GHC. What would happen if I cabal-dev install foo instead? Would I be able to avoid breaking GHC? Could I actually make use of the foo package in a cabal-dev sandbox, or would it just be a broken sandbox?
Example: yesod, GHC 7.4.1, cabal-dev 0.9 built from github source, Cabal 1.14.0 library.
Just to clarify, if I am understanding you right, you are not breaking GHC in either case. I believe you are referring to installing a package, which then reinstalls one of the underlying dependencies of another package, therefore breaking that other package’s dependency chain and preventing it from properly working/compiling when used. Simply removing .ghc from your home folder and re-doing cabal installs typically resolves this problem, albeit in a really painful way.
When you use cabal-dev, all the cabal install steps and ghc-pkg register steps are done in a local sandbox environment. Your global/user ghc packages are not at all touched. Since you typically instantiate one cabal-dev sandbox per project, clashes like described above don’t typically happen.
To get to your question – it depends entirely on what is already installed in that particular cabal-dev sandbox. If there are no conflicts, it wouldn’t break anything. If you are forcing a
--reinstall, you might have to--reinstallany packages in the local cabal-dev sandbox that depend on the package you just reinstalled.In any case, your GHC installation itself would not break (or be altered in any way) and you can always
rm -rf cabal-devunder your project folder and redocabal-dev install.Hope this helps.