Johannes Waldmann | 17 Apr 10:10 2013
Picon

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.
Ivan Lazar Miljenovic | 17 Apr 10:15 2013
Picon

Re: version of containers fixed by template-haskell?

On 17 April 2013 18:10, Johannes Waldmann <waldmann <at> imn.htwk-leipzig.de> wrote:
> 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.
>
>
>
> _______________________________________________
(Continue reading)

Roman Cheplyaka | 17 Apr 10:29 2013

Re: version of containers fixed by template-haskell?

* Johannes Waldmann <waldmann <at> imn.htwk-leipzig.de> [2013-04-17 08:10:21+0000]
> (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
Johannes Waldmann | 17 Apr 10:36 2013
Picon

Re: version of containers fixed by template-haskell?

Roman Cheplyaka <roma <at> ro-che.info> 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))?
Roman Cheplyaka | 17 Apr 11:14 2013

Re: version of containers fixed by template-haskell?

On second thought, are you trying to install it globally?

ghc is installed globally, and local packages should not "break" it. 

* Johannes Waldmann <waldmann <at> imn.htwk-leipzig.de> [2013-04-17 08:36:23+0000]
> Roman Cheplyaka <roma <at> ro-che.info> 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))?
Johannes Waldmann | 17 Apr 13:54 2013
Picon

Re: version of containers fixed by template-haskell?

Roman Cheplyaka <roma <at> ro-che.info> writes:

> On second thought, are you trying to install it globally? 

locally

> ghc is installed globally, and local packages should not "break" it. 

still cabal-install says so (and I don't dare to test ...)
Andres Löh | 17 Apr 14:28 2013
Picon

Re: version of containers fixed by template-haskell?

>> 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

Gmane