Cabal install performs worse on Hugs
Hi, Using Cabal 1.4 Branch and Cabal-install HEAD: C:\Neil\uniplate>cabal install --hugs Resolving dependencies... cabal: internal error: could not construct a valid install plan. The proposed (invalid) plan contained the following problems: Package uniplate-1.1 has an invalid configuration, in particular: the package has a dependency base >=3 but no package has been selected to sati sfy it. the package has a dependency containers -any but no package has been selected to satisfy it. the package has a dependency mtl -any but no package has been selected to sati sfy it. But doing it the old way: C:\Neil\uniplate>runhaskell Setup configure --hugs Configuring uniplate-1.1... C:\Neil\uniplate>runhaskell Setup build Preprocessing library uniplate-1.1... Building uniplate-1.1... C:\Neil\uniplate>runhaskell Setup install Installing: C:\Program Files\Haskell\hugs\packages\uniplate Registering uniplate-1.1... It seems like if cabal install is incapable of doing anything good on Hugs, it should at least try to see if it works already. Thanks Neil
On Sat, 2008-06-14 at 15:05 +0100, Neil Mitchell wrote:
Hi,
Using Cabal 1.4 Branch and Cabal-install HEAD:
C:\Neil\uniplate>cabal install --hugs Resolving dependencies... cabal: internal error: could not construct a valid install plan. The proposed (invalid) plan contained the following problems: Package uniplate-1.1 has an invalid configuration, in particular: the package has a dependency base >=3 but no package has been selected to sati sfy it. the package has a dependency containers -any but no package has been selected to satisfy it. the package has a dependency mtl -any but no package has been selected to sati sfy it.
We changed the dependency resolution stuff a lot and have not updated the grievous hacks required to do anything sensible when we do not know what is installed. Generating install plans with hugs is actually impossible which does make things a bit tricky to do in a regular way since we do now rather rely on install plans as a unifying abstraction.
But doing it the old way:
Which does not try to make an install plan.
It seems like if cabal install is incapable of doing anything good on Hugs, it should at least try to see if it works already.
I'll think about it a bit more. Duncan
On Sun, 2008-06-15 at 21:00 +0100, Duncan Coutts wrote:
On Sat, 2008-06-14 at 15:05 +0100, Neil Mitchell wrote:
Hi,
Using Cabal 1.4 Branch and Cabal-install HEAD:
C:\Neil\uniplate>cabal install --hugs Resolving dependencies... cabal: internal error: could not construct a valid install plan. The proposed (invalid) plan contained the following problems: Package uniplate-1.1 has an invalid configuration, in particular: the package has a dependency base >=3 but no package has been selected to sati sfy it. the package has a dependency containers -any but no package has been selected to satisfy it. the package has a dependency mtl -any but no package has been selected to sati sfy it.
We changed the dependency resolution stuff a lot and have not updated the grievous hacks required to do anything sensible when we do not know what is installed.
Generating install plans with hugs is actually impossible which does make things a bit tricky to do in a regular way since we do now rather rely on install plans as a unifying abstraction.
Actually it's not impossible. We just have to lie. We can make a valid install plan so long as we do not require that it reflect reality. The trick is to make one where we say that all the dependencies are already installed. So we fake it by making up exactly the installed dependencies that we know we need. We then say that each of those deps has no other deps and we're done. Duncan
On Sat, 2008-06-14 at 15:05 +0100, Neil Mitchell wrote:
Hi,
Using Cabal 1.4 Branch and Cabal-install HEAD:
C:\Neil\uniplate>cabal install --hugs Resolving dependencies...
Should work now. Also "cabal install --hugs whatever" should also work. It assumes that all deps of "whatever" are already installed. It can still go wrong. Suppose foo build-depends on bar < 2 but bar-2.0 is available, then: $ cabal install foo bar will will (probably) succeed, however it will pick bar-2.0 because it's the latest available, even though foo cannot work with bar-2.0. Perhaps there is in fact a way of working out what hugs packages are installed. Each package that comes with hugs (2006.9 at least) has a Paths_pkgname.hs module and it defines: version = Version [...] [] So it would be possible to parse this to get the versions of all installed packages. Duncan
participants (2)
-
Duncan Coutts -
Neil Mitchell