for every install there should be an uninstall

[bos]

(Imported from Trac #655, reported by nr on 2010-04-07)

This is a feature request for a 'cabal uninstall' that will undo
all the effects of a 'cabal install'. This should include

• Unregistering the package with ghc-pkg
• Recovering the disk space
• Removing from indices and documentation
• Transitively uninstalling packages that were installed only to satisfy dependencies of this package, all of whose dependencies are dead.

That last bullet could be a bit of a problem, but the first three should be straightforward I hope.

[bos]

(Imported comment by @dcoutts on 2010-04-07)

This is mostly a duplicate of ticket #234.

The last point is slightly different. It would be possible only for packages installed via the cabal program, not via other agents. It would involve using the "world" file as in ticket #199. That records which packages were specifically requested.

[bos]

(Imported comment by nr on 2010-04-08)

This is still an issue. I am having a dependency problem with pads-haskell-0.2 and haskell-src-meta-0.4. haskell-src-meta-0.4 depends on haskell-src-exts in the range 1.6 to 1.0. But with haskell-src-exts-1.9, pads-haskell will not build. With haskell-src-exts-1.10.2, pads-haskell will build.

My machine has both versions of haskell-src-exts. But I cannot add the higher dependency to pads-haskell.cabal without extensive bleating. There is clearly an underlying dependency problem here that ought to be addressed, but my immediate concern is to get software to build. If 'cabal uninstall' existed, I could uninstall the older packages and continue. As it is, the only way I know to make progress is to remove all of ~/.cabal and start over. Not a good model.

[bos]

(Imported comment by guest on 2011-05-17)

There are a few options, one of which might get you unstuck:

You can reinstall a package:

cabal install --reinstall haskell-src-exts-1.10.2

Or you could use ghc-pkg unregister instead of cabal uninstall ...

For a long term solution, I would recommend using cabal-dev to install packages in their own sandboxes where their dependencies won't affect the build of other things on your machine.

[bos]

(Imported comment by @BenMachine on 2011-05-18)

haskell-src-meta is my package – and it should build with haskell-src-exts-1.10.2. Maybe try reinstalling haskell-src-meta (although that might break anything else that depends on it).

[bos]

(Imported comment by @dcoutts on 2011-05-18)

Replying to nr:

This is still an issue. I am having a dependency problem with pads-haskell-0.2 and haskell-src-meta-0.4. haskell-src-meta-0.4 depends on haskell-src-exts in the range 1.6 to 1.0. But with haskell-src-exts-1.9, pads-haskell will not build. With haskell-src-exts-1.10.2, pads-haskell will build.

Ok, so if I understood correctly we have:

pads-haskell-0.2: depends on both haskell-src-meta and haskell-src-exts >= 1.10
haskell-src-meta-0.4: depends on haskell-src-exts >= 1.0 && < 1.9

Which is not solvable because their constraints on haskell-src-exts are inconsistent. One or other package would need to be modified so that they can agree on a common version of haskell-src-exts.

If this is really the situation then no amount of installing and uninstalling will help.

But I don't think it is the situation, looking on hackage it says that haskell-src-meta-0.4 depends on haskell-src-exts >= 1.6 && < 1.11.

My machine has *both* versions of haskell-src-exts.

That's fine, but in the solution there can only be one instance of each package.

But I cannot add the higher dependency to pads-haskell.cabal without extensive bleating. There is clearly an underlying dependency problem here that ought to be addressed, but my immediate concern is to get software to build. If 'cabal uninstall' existed, I could uninstall the older packages and continue. As it is, the only way I know to make progress is to remove all of ~/.cabal and start over. Not a good model.

No, I don't understand. If removing packages would help solve the situation then the above description of the version constraints cannot be right.

If the situation has a straightforward solution you should be able to do:

$ cd pads-haskell/
$ cabal install --dry-run

And it'll replan everything to try and find some combination of versions that works. The sovler is quite happy to reinstall things to achieve a solution.

It sounds to me like you've been installing individual packages manually and trying to construct a solution that way. The far easier approach is using cabal install --dry-run to construct the whole solution in one go, and if necessary adding --constraint= flags to guide the solver, e.g. --constraint="haskell-src-exts >= 1.10".

Note also, that this dependency issue is mostly orthogonal to the lack of uninstall feature. For finding solutions it doesn't really matter what is currently installed. It is also possible to eliminate registered packages using ghc-pkg unregister. A cabal uninstall feature would just add recovering the disk space. (Not that that is not important, but is is an independent issue from dependency solving.)

Overall, I think we need more clarity on the situation you're looking at and what you've been trying.

[DanBurton]

As a first step, how about this:

cabal uninstall PACKAGE prints the following message:

Cabal is not a package manager, and does not support the "uninstall" operation.
Try this command instead:
ghc-pkg unregister PACKAGE

And exitFails.

If a sandbox is present, then ideally include it in the suggested command

Cabal is not a package manager, and does not support the "uninstall" operation.
Try this command instead:
ghc-pkg unregister PACKAGE --package-db=/path/to/packagedb/as/found/in/cabal/sandbox/config

See: Suggestion from sclv on reddit.

[lspitzner]

cabal sandbox hc-pkg -- unregister $PACKAGE

[DanBurton]

Sure, the message could suggest that instead.

[fgaz]

With v2- commands, this will probaby be #6481 + #3333