patch applied (cabal-install): Disable cabal upgrade and add cabal install --upgrade-dependencies

Mon May 31 06:03:06 PDT 2010 Duncan Coutts

On 31 May 2010 15:18, Duncan Coutts
Mon May 31 06:03:06 PDT 2010 Duncan Coutts
* Disable cabal upgrade and add cabal install --upgrade-dependencies cabal upgrade now gives an error message telling people to use install or, if they know what they're doing, install --upgrade-dependencies
How about also adding a reference to 'cabal install world'? I think that's the behaviour most people actually want when running upgrade (at least I do :) ). Peter
M ./Distribution/Client/Install.hs -45 +16 M ./Distribution/Client/Setup.hs -1 +10 M ./Main.hs -1 +1
View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=cabal-install;a=darcs_commit...
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

On Tue, 2010-06-01 at 16:48 +0200, Peter Robinson wrote:
On 31 May 2010 15:18, Duncan Coutts
wrote: Mon May 31 06:03:06 PDT 2010 Duncan Coutts
* Disable cabal upgrade and add cabal install --upgrade-dependencies cabal upgrade now gives an error message telling people to use install or, if they know what they're doing, install --upgrade-dependencies How about also adding a reference to 'cabal install world'? I think that's the behaviour most people actually want when running upgrade (at least I do :) ).
Yes, I was thinking about that. I think we need a little more work before the world feature is recommended to the masses. http://hackage.haskell.org/trac/hackage/ticket/695 As you point out, we would really need to start tracking programs. The other thing I'm not yet convinced about is keeping just the flags in the world file. I suspect we'll need more eventually and should perhaps plan the format with that in mind. Also currently we do not properly assign flags to individual packages, that's not the fault of the world feature, it's a problem elsewhere in cabal-install. Don't get me wrong, the world feature is definitely what we need (and works well for distros) but generally I think we need more experience of how it works in practise. I suspect one of the first things we'll find is that the dep resolver runs into problems when trying to install world. While it could find install plans for each package individually it might not be able to find a plan for all the world packages simultaneously. We may need some significant improvements in the solver and we might have to do things like treating the flags etc as suggestions rather than hard "all or nothing" constraints. Duncan

On 1 June 2010 18:52, Duncan Coutts
On Tue, 2010-06-01 at 16:48 +0200, Peter Robinson wrote:
On 31 May 2010 15:18, Duncan Coutts
wrote: Mon May 31 06:03:06 PDT 2010 Duncan Coutts
* Disable cabal upgrade and add cabal install --upgrade-dependencies cabal upgrade now gives an error message telling people to use install or, if they know what they're doing, install --upgrade-dependencies How about also adding a reference to 'cabal install world'? I think that's the behaviour most people actually want when running upgrade (at least I do :) ).
Yes, I was thinking about that. I think we need a little more work before the world feature is recommended to the masses.
http://hackage.haskell.org/trac/hackage/ticket/695
As you point out, we would really need to start tracking programs.
Yes, I guess tracking programs will be necessary, although this might not be as urgent as the dep resolver problems. I suppose this is also highly related to the uninstall feature.
The other thing I'm not yet convinced about is keeping just the flags in the world file. I suspect we'll need more eventually and should perhaps plan the format with that in mind. Also currently we do not properly assign flags to individual packages, that's not the fault of the world feature, it's a problem elsewhere in cabal-install.
You're probably right. For the time being, however, I would settle for getting the simple file format to work without problems. :)
Don't get me wrong, the world feature is definitely what we need (and works well for distros) but generally I think we need more experience of how it works in practise. I suspect one of the first things we'll find is that the dep resolver runs into problems when trying to install world. While it could find install plans for each package individually it might not be able to find a plan for all the world packages simultaneously. We may need some significant improvements in the solver and we might have to do things like treating the flags etc as suggestions rather than hard "all or nothing" constraints.
Hmm, yes I've noticed running into problems once the world file reaches
10 lines. At the moment I don't really see how to make the current resolver algorithm handle this issue, but I'll need to take a closer look at the code.
Peter

On Wed, 2010-06-02 at 12:32 +0200, Peter Robinson wrote:
On 1 June 2010 18:52, Duncan Coutts
wrote: On Tue, 2010-06-01 at 16:48 +0200, Peter Robinson wrote:
On 31 May 2010 15:18, Duncan Coutts
wrote: Mon May 31 06:03:06 PDT 2010 Duncan Coutts
* Disable cabal upgrade and add cabal install --upgrade-dependencies cabal upgrade now gives an error message telling people to use install or, if they know what they're doing, install --upgrade-dependencies How about also adding a reference to 'cabal install world'? I think that's the behaviour most people actually want when running upgrade (at least I do :) ).
Yes, I was thinking about that. I think we need a little more work before the world feature is recommended to the masses.
http://hackage.haskell.org/trac/hackage/ticket/695
As you point out, we would really need to start tracking programs.
Yes, I guess tracking programs will be necessary, although this might not be as urgent as the dep resolver problems.
Hmm, not sure.
I suppose this is also highly related to the uninstall feature.
It's related but I don't think one strictly depends on the other.
The other thing I'm not yet convinced about is keeping just the flags in the world file. I suspect we'll need more eventually and should perhaps plan the format with that in mind. Also currently we do not properly assign flags to individual packages, that's not the fault of the world feature, it's a problem elsewhere in cabal-install.
You're probably right. For the time being, however, I would settle for getting the simple file format to work without problems. :)
So long as we can upgrade it later...
Don't get me wrong, the world feature is definitely what we need (and works well for distros) but generally I think we need more experience of how it works in practise. I suspect one of the first things we'll find is that the dep resolver runs into problems when trying to install world. While it could find install plans for each package individually it might not be able to find a plan for all the world packages simultaneously. We may need some significant improvements in the solver and we might have to do things like treating the flags etc as suggestions rather than hard "all or nothing" constraints.
Hmm, yes I've noticed running into problems once the world file reaches
10 lines. At the moment I don't really see how to make the current resolver algorithm handle this issue, but I'll need to take a closer look at the code.
It is a question of what behaviour we want. Currently these two commands mean different things: cabal install foo; cabal install bar vs cabal install foo bar The key difference is that the latter guarantees that both foo and bar can be used together in a single program, with consistent dependencies. With the former, it might be that the two packages disagree on the version of a common dependency. So currently cabal install world means try to install all the world packages such that they all have consistent dependencies. This gets increasingly difficult with more packages, and sometimes it is impossible. Having a smarter dep resolver will help find the consistent install plan for all world packages in more situations. It is also worth considering using a looser consistency model where we make sure the deps of each package individually are consistent, but do not provide global consistency. The downside is that it will not necessarily be possible to use all combinations of packages at once. Duncan
participants (2)
-
Duncan Coutts
-
Peter Robinson