version of containers fixed by template-haskell?
Is it still the case that "It just doesn't work to have multiple versions of a wired-in package" (cf. http://hackage.haskell.org/trac/ghc/ticket/5704 )? ghc-7.6.2 comes with containers-0.5.0.0 and template-haskell-2.8.0.0 . It seems I can upgrade to containers-0.5.2.1 and use it with no problems but not alongside template-haskell: ... changes: containers-0.5.0.0 -> 0.5.2.1, Warning: The following packages are likely to be broken by the reinstalls: ... ghc-7.6.2 (Isn't it somewhat bold of cabal-install to offer to break "ghc-7.6.2"? like, this will completely hose the compiler?) That's bad, because I use containers everywhere, and I assume that 0.5.2.1 has some advantages (like, speed) over 0.5.0.0. - J.W.
On 17 April 2013 18:10, Johannes Waldmann
Is it still the case that "It just doesn't work to have multiple versions of a wired-in package" (cf. http://hackage.haskell.org/trac/ghc/ticket/5704 )?
ghc-7.6.2 comes with containers-0.5.0.0 and template-haskell-2.8.0.0 . It seems I can upgrade to containers-0.5.2.1 and use it with no problems but not alongside template-haskell:
template-haskell depends upon containers; as such, if you try and use a different version of containers whilst also using template-haskell you're going to run into the diamond dependency problem: http://www.well-typed.com/blog/9#
... changes: containers-0.5.0.0 -> 0.5.2.1, Warning: The following packages are likely to be broken by the reinstalls: ... ghc-7.6.2
(Isn't it somewhat bold of cabal-install to offer to break "ghc-7.6.2"? like, this will completely hose the compiler?)
That's bad, because I use containers everywhere, and I assume that 0.5.2.1 has some advantages (like, speed) over 0.5.0.0.
- J.W.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com
* Johannes Waldmann
(Isn't it somewhat bold of cabal-install to offer to break "ghc-7.6.2"? like, this will completely hose the compiler?)
ghc is the package that provides the GHC API. Breaking it should not affect the compiler itself, since it is statically linked. Roman
On second thought, are you trying to install it globally?
ghc is installed globally, and local packages should not "break" it.
* Johannes Waldmann
Roman Cheplyaka
writes: ghc is the package that provides the GHC API. Breaking it should not affect the compiler itself, since it is statically linked.
Yes. But once ghc (the package) is broken, it cannot be fixed (except by re-installing ghc (the compiler))?
ghc is installed globally, and local packages should not "break" it.
still cabal-install says so (and I don't dare to test ...)
If you're installing locally or (even better) in a sandbox, then you cannot completely (i.e., irrevocably) break your compiler. You can always remove the package db. Yes, Cabal warns you nevertheless, because if the user package db is your current context, the ghc package will subsequently be broken in that context, and that can be bad/inconvenient enough in practice. Cheers, Andres
participants (4)
-
Andres Löh -
Ivan Lazar Miljenovic -
Johannes Waldmann -
Roman Cheplyaka