On Sun, 2009-10-04 at 10:32 -0700, John Millikin wrote:

I'm writing a library that needs to parse both plain text (with Parsec) and XML (with HXT). HXT's .cabal file specifies that it only works with parsec (>= 2.1 && < 3), but it still builds when I depend on parsec >= 3. It's only during "cabal install" that the following error is displayed:

- -------------------------------------------- Resolving dependencies... cabal-1.7.3: cannot configure hxt-8.3.1. It requires parsec >=2.1 && <3 For the dependency on parsec >=2.1 && <3 there are these packages: parsec-2.1.0.0 and parsec-2.1.0.1. However none of them are available. parsec-2.1.0.0 was excluded because dbus-core-0.5 requires parsec >=3.0.0 parsec-2.1.0.1 was excluded because dbus-core-0.5 requires parsec >=3.0.0 - --------------------------------------------

Is there a good solution to this?

Not really. Not at the moment. We have this restriction because of the dreaded diamond dependency problem: http://blog.well-typed.com/2008/04/the-dreaded-diamond-dependency-problem/ It's likely that this problem would not actually occur in your example because presumably HXT does not re-export types from the parsec package. However cabal does not have enough information to know that it does not, so it takes the conservative view. We could do rather better if we could declare private or public dependencies. The point with private ones being that you'd not be allowed to use types from the private package in your public API. In your example parsec would probably be a private dependency of HXT and thus we would not care what version of parsec it was using, it couldn't cause any problems.

I was thinking about changing my library to use Parsec 2, but that just pushes the problem to my users, it doesn't really solve it.

Right. Duncan