7

I'm confused by how Cabal works. I'm used to packages managers that have as part of their core functionality the ability to easily update all packages that have changed, or at least to get a list of packages on my system that have updates available. But Cabal seems to lack this functionality. Am I missing something?

Is there a way to:

  1. Automatically or easily update all out-of-date packages; or, failing that,
  2. Get a list of packages installed on my system that have updates available?
Antal Spector-Zabusky
  • 36,191
  • 7
  • 77
  • 140
orome
  • 45,163
  • 57
  • 202
  • 418
  • Almost all `cabal` packages are not dependent on the newest version of a dependency package, but rather a specific version of that dependency. `Cabal` resolves the dependencies by downloading the *required* package version not the *newest* package version. – recursion.ninja Aug 18 '15 at 16:35
  • @recursion.ninja: Is there a way to do (2) — wait, where'd my numbers go?! —that is, to get a list of the packages that have updates relative to those currently on my system? – orome Aug 18 '15 at 16:37
  • @recursion.ninja: And, I'm not sure I understand the model. Say, for example, the version of X (which depends on a, b, and c which have not changed, and on p, q, and r, which have) I have is older than the current version, and I'd like to upgrade it. How am I to proceed to update X? (Using pip for Python, for example I'd just update X, p, q, and r — or more succinctly, update X which would update p, q, and r — and I'd be done; no worries.) – orome Aug 18 '15 at 16:40
  • `cabal update && cabal info packageName`. Look at the output to see the available version numbers for `packageName`. This will show you all the available versions and which version(s) you have installed. To install a specific version, such as a newer version do the following: `cabal install packageName-1.2.3.4` where `1.2.3.4` is the newer version number. – recursion.ninja Aug 18 '15 at 16:47
  • 2
    You should note that installing a newer version **will not** link the newer version to other packages that depend on `packageName`. – recursion.ninja Aug 18 '15 at 16:50
  • @recursion.ninja: To a pip user, if the only option is to wade through the output of `cabal info`, then it sounds like the answer to (2) is "no". – orome Aug 18 '15 at 17:04
  • You are correct, you might be able to come up with some slick `awk` & `sed` command to generate the list from `cabal info` output after iterating over the results of `ghc-pkg list`... – recursion.ninja Aug 18 '15 at 17:11

1 Answers1

14

There are a number of standard package-management features missing from cabal. This is one of them, and (transitive) removal of packages is another. The party line is that cabal is intended to be an automatic build tool, nothing more; though that line grows thinner and thinner as the years drag on.

If you know which packages you want to upgrade, you can; generally cabal update and cabal install those packages will grab the newest package list from Hackage and try to find an install plan that installs the newest versions of the requested packages. You can ask for the install plan without executing it with cabal install --dry-run those packages; if it doesn't look like it picked the versions you want, you can add constraints, as in

cabal install those packages --constraint 'those>=9000'
Daniel Wagner
  • 145,880
  • 9
  • 220
  • 380
  • Does running [this workaround](http://stackoverflow.com/a/6905267/656912) periodically make sense? – orome Aug 18 '15 at 17:05
  • 1
    @raxacoricofallapatorius I would advise against running it automatically periodically. Just run it when you discover that you *need* a newer version of a package and the `cabal install packageName-1.2.3.4` can't resolve dependencies due to already installed packages. Expect at least an hour of recompiling many packages... – recursion.ninja Aug 18 '15 at 17:13
  • @raxacoricofallapatorius That looks like a stupendous way to initiate what is colloquially known as "cabal hell". (At the very least, you should tell cabal about *all* the packages you want to reinstall in one command, rather than running one command per package.) On the other hand, figuring your way out of cabal hell a few times will teach you a lot about how cabal works... – Daniel Wagner Aug 18 '15 at 17:13
  • Yes, it seems like maybe that workaround with `--dry-run` instead of `--reinstall`, might yield some information that could be used as a starting point for targeted reinstalls as necessary. "Cabal Hell" seems redundant to me. – orome Aug 18 '15 at 17:19
  • @raxacoricofallapatorius By the way, you might like [SICP](http://www.vex.net/~trebla/haskell/sicp.xhtml). – Daniel Wagner Aug 18 '15 at 17:26
  • So suppose that the Haskel Platform changes (say GHC is updated). What do I need to do to update my configuration, which includes (a) several additional packages, and (b) IHaskell, which is (c) installed into Jupyter? Do I need to remove the platform, re-install it, reinstall my additional packages, reinstall IHaskel, and re-run `ihaskell install`? (I'm loosing my interest in Haskell.) – orome Aug 18 '15 at 17:37
  • @raxacoricofallapatorius I don't know much about ihaskell or jupyter. It might be worth opening a fresh question with further details about what you want to do. That said, you should not need to remove anything during a GHC upgrade. – Daniel Wagner Aug 18 '15 at 18:53
  • @raxacoricofallapatorius, all package management tools suck. They just all suck differently. Cabal has the advantage of failing loudly and early, and the accompanying disadvantages. Cabal sandboxes can ease the pain, and some people swear by Stackage. Others reach in a whole different direction and use Nix. You don't *need* to use cabal as anything but a build tool I'd you don't want to. – dfeuer Aug 19 '15 at 03:07
  • @dfeuer: Yes. I'm just having trouble wrapping my mind around how the Haskell environment works, and Cabal seemed to make it unnecessarily fiddly to manage. – orome Aug 19 '15 at 10:55
  • "Cabal is not a Package Manager" - https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ – Alex Trueman May 25 '17 at 17:50