QRE: Cabal and simultaneous installations of the same package
| But if multiple versions of the same library can be linked into one | binary, then the binary sizes will increase and therefore the memory | usage might increase and even performance might decrease a bit if the | number of cache misses increase. Well, no one is actually suggesting that! The #1 issue is that installing package P1, which depends on Q-3.4, should not break other package P2 that also depends on Q-3.4. Today it can break P2. And re-installing P2 can break P1. How does that happen? Q-3.4 depends on R 1.4-3.8 P1 depends on R-1.4 P2 depends on R-2.8 Then P1 needs Q-3.4 compiled against R-1.4 P2 needs Q-3.4 compiled against R-2.8 So the two can only co-exist if both instances of Q-3.4 can be simultaneously installed. None of this means that both instances of Q-3.4 need be part of the same executable. (That would be necessary if you wanted P1 and P2 in the same program; but maybe you don't.) They certainly could be, but allowing it has the disadvantages you describe. Simon | -----Original Message----- | From: Daniel Trstenjak [mailto:daniel.trstenjak@gmail.com] | Sent: 11 May 2015 12:05 | To: Simon Peyton Jones | Cc: Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan@well- | typed.com); Ryan Trinkle; haskell-infrastructure@community.galois.com; | cabal-devel@haskell.org; ghc-devs@haskell.org; Vishal Agrawal; Haskell | Libraries | Subject: Re: Cabal and simultaneous installations of the same package | | | Hi Simon, | | > It is tantalising to me that something so critical has been so long | delayed. | > It’d be fantastic if it was done this summer. | | I'm just wondering what kind of negative side effects it might have. | | Sure, it will - most likely - make installing of cabal packages a lot | easier, especially for all non expert Haskell users. | | But if multiple versions of the same library can be linked into one | binary, then the binary sizes will increase and therefore the memory | usage might increase and even performance might decrease a bit if the | number of cache misses increase. | | It's certainly annoying to keep up with library updates, but in a way | it also pushes everyone forward to update their code bases, so if | everything just "works" - respectively is easy buildable - then this | force might be quite reduced. | | I'm just thinking e.g. of a case where you want to use at least a | certain version of a library, because you know of major | performance/bug fixes in this version, but now a considerable part of | your code base might use an older version of this library, because the | dependencies of your project haven't been updated. | | | Greetings, | Daniel
Hi Simon, On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote:
Well, no one is actually suggesting that!
But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary. Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state. Greetings, Daniel
As I think Simon was saying earlier, think of this feature as allowing
strictly more installation plans to succeed, while still keeping to the
exact same model that we use today of just one instance of a lib in any
given binary.
Currently, if you install B-0.1 and then install A-2.0 that has a
constraint B>=0.1, then you can't build an app that depends on both A and
B-0.2. That's counter intuitive because had you started from an empty
sandbox, then you would be able to build the app!
The reason is that currently you can only have a single instance of A-2.0
installed. The proposal is *not* to allow building an app against an A-2.0
built against B-0.1 and against B-0.2 simultaneously. It's to allow
multiple instances of A-2.0 in the same package database, and teach Cabal
to handle that, so that an app can ask for an A-2.0 that is built against
the right version of B, no matter what, and link that in.
In your example, an app wouldn't get both C 1.0 and 2.0. It would get
whichever one of those fits the constraints of both A and B, or the build
will fail if no such C exists.
Since only one instance of a library ever makes it into a binary, as is the
case currently, no particular problem arises with linking in external
dependencies such as C code.
On 11 May 2015 at 14:52, Daniel Trstenjak
Hi Simon,
On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote:
Well, no one is actually suggesting that!
But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0.
Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary.
Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state.
Greetings, Daniel _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
On Mon, May 11, 2015 at 05:42:00PM +0200, Boespflug, Mathieu wrote:
In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists.
Thanks for the clarification! I thought this was part of the proposal, sorry for the noise. Greetings, Daniel
Exactly! It’s so close! GHC has all the necessary infrastructure. All we need is for Cabal to recognise that it’s possible to install two instances of A-2.0. My fingers can almost touch it. Go Vishal!
Simon
From: Boespflug, Mathieu [mailto:m@tweag.io]
Sent: 11 May 2015 16:42
To: Simon Peyton Jones; Gershom B; Mikhail Glushenkov; Duncan Coutts (duncan@well-typed.com); Ryan Trinkle; haskell-infrastructure@community.galois.com; cabal-devel@haskell.org; ghc-devs@haskell.org; Vishal Agrawal; Haskell Libraries
Subject: Re: QRE: Cabal and simultaneous installations of the same package
As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just one instance of a lib in any given binary.
Currently, if you install B-0.1 and then install A-2.0 that has a constraint B>=0.1, then you can't build an app that depends on both A and B-0.2. That's counter intuitive because had you started from an empty sandbox, then you would be able to build the app!
The reason is that currently you can only have a single instance of A-2.0 installed. The proposal is *not* to allow building an app against an A-2.0 built against B-0.1 and against B-0.2 simultaneously. It's to allow multiple instances of A-2.0 in the same package database, and teach Cabal to handle that, so that an app can ask for an A-2.0 that is built against the right version of B, no matter what, and link that in.
In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists.
Since only one instance of a library ever makes it into a binary, as is the case currently, no particular problem arises with linking in external dependencies such as C code.
On 11 May 2015 at 14:52, Daniel Trstenjak
Well, no one is actually suggesting that!
But you're just getting it automatically if you're depending e.g. on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0. Currently you can't build this dependency graph, right? And with this proposed feature you will be getting C 1.0 and 2.0 into your binary. Perhaps a even more nasty case is, if you're using a haskell library which wraps a stateful c library, and now you're having multiple versions of the same haskell library operating on the same c library state. Greetings, Daniel _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (3)
-
Boespflug, Mathieu -
Daniel Trstenjak -
Simon Peyton Jones