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

[Jason Dagit]

On Wed, Sep 15, 2010 at 7:47 PM, Peter Schmitz <ps.haskell at gmail.com> 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