Re: [Haskell-cafe] Curious why "cabal upgrade parsec" not installing latest version

Jason, Thank you for the insights into Cabal. I am new to Parsec, and relatively new to Cabal, and was not aware of the info that you (and Thomas and Ivan) posted. Great help; thanks again. I will probably stick with Cabal's default for the time being because I don't have a compelling reason not to, but it's good to know how Cabal works. I am finding developing in Haskell + Gtk2Hs + Glade + Parsec a lot of fun. Parser combinators are so cool. -- Peter On Wed, Sep 15, 2010 at 8:15 PM, Jason Dagit wrote:

On Wed, Sep 15, 2010 at 7:47 PM, Peter Schmitz wrote:

...

Not that I'm having any problem with parsec 2.1.0.1, but I guess I would like to install the latest (3.1.0), unless there is a reason not to.

I can't seem to get Cabal to do so; thanks in advance for any help.

I don't understand part of the output from "cabal install --dry-run --reinstall -v parsec" at the end below, which includes: "selecting parsec-2.1.0.1 (hackage) and discarding parsec-2.0, 2.1.0.0, 3.0.0, 3.0.1 and 3.1.0".

(http://hackage.haskell.org/package/parsec seems to point to 3.1.0.)

I consider this a misfeature of cabal-install.  Cabal-install will check here: http://hackage.haskell.org/packages/archive/preferred-versions

Before deciding out how to handle an 'install' request.  You'll notice that it says: parsec < 3

Sadly cabal-install doesn't warn you or ask what version you want. There is an unwritten policy that cabal knows better than you do about what packages you want.  And then it silently enforces it's point of view on you unless you specify a conflicting constraint.  And unless the package is base, in which case it only listens if you either a) give an upper bound on base, or b) provide a preference (instead of a constaint).

You can work around these (broken) global policies by editing your local cabal config.  Should be in $HOME/.cabal/config (or the similar place on windows).  You can add a line like: preference: base >= 4, parsec >= 3

That should help to nullify the global policy.

Cabal bugs not withstanding, this comes about because cabal is not a package manager.  Unlike distributions like Debian there is no way to subscribe to 'stable', 'experimental', or 'developer only' package classifications.  Unfortunately, the current 'solution' has been to enforce a 'one size fits all' policy on users with an essentially undocumented way to override it (which has to be applied for each cabal-install installation).  I assume this strategy was picked because it was easy to implement and developer time can be scarce.

Jason