Just cleaning out my inbox and realised I meant to reply to this about 4 months ago :-) On Thu, 2008-09-04 at 23:15 -0700, Iavor Diatchki wrote:
On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts
Packages are not supposed to expose different APIs with different flags so I don't think that's right. Under that assumption cabal-install can in principle resolve everything fine. I'm not claiming the current resolution algorithm is very clever when it comes to picking flags (though it should always pick ones that give an overall valid solution) but there is certainly scope for a cleverer one. Also, the user can always specify what features they want, which is what systems like Gentoo do.
Do you have any specific test cases where the current algorithm is less than ideal? It'd be useful to report those for the next time someone hacks on the resolver.
The examples that I was thinking of arise when libraries can provide conditional functionality, depending on what is already installed on the system, a kind of "co-dependecy". [...]
I guess, you could say that we structured the library wrong---perhaps we should have had a core package that only provides manual parsing (no external libraries required), and then have a separate packages for each of the parsers that use a different parsing combinator library.
Conceptually, this might be better, but in practice it seems like a bit of a pain---each parser is a single module, but it would need a whole separate directory, with a separate cabal file, license, and a setup script, all of which would be almost copies of each other.
Right, I admit it might be handy. Unfortunately we could not translate such packages into other packaging systems because I don't know of any standard native packaging systems that allow such co-dependencies. They have to be translated into multiple packages. If we did support such conditional stuff it would have to be explicit to the package manager because otherwise choices about install order would change the exposed functionality (indeed it might not even be stable / globally solvable). In particular I've no idea what we should do about instances. Where we'd like to provide an instance for a class defined in another package that we do not directly need (except to be able to provide the instance). If we did not have the constraint of wanting to generate native packages then there are various more sophisticated things we could do, but generating native packages is really quite important to our plans for world domination. Duncan