On Wed, Nov 01, 2006 at 01:34:35AM +0000, Duncan Coutts wrote:
On Wed, 2006-11-01 at 01:13 +0000, Ian Lynagh wrote:
flag: fps_in_base default: available(base >= 2)
configuration: fps_in_base build-depends: base(>= 2)
configuration: !fps_in_base build-depends: base(< 2), fps
The user would be able to shoot themselves in the foot by overidding the fps_in_base flag such that they don't have the deps installed, but that's their own fault. Note that the right thing will happen if they just leave it as the default.
Yeah it'd work but I don't like it.
It exposes too much to the user for one thing. It's not always going to do the the right thing either. In this case you can only have one version of base installed at once, but for other libs that's not the case. So imagine I do have base-1.0 and 2.0 installed then there's no guarantee that the version that end up meaning the test comes out true is the same one we're using.
I'm not following; with what I wrote above, the base we end up using would make the flag have the value it does. You could certainly write a buggy .cabal file, but there are many ways you can do that without even using advanced features, e.g. build-depends: foo (== 1) build-depends: foo (== 2) You could, if you so wished, force fps_in_base to be false even if you had both bases, in which case it would use base 1. But presumably you wanted that to happen... (that makes me think of something else - we probably want the user to be able to tell cabal "I want to use this version foo"; this should probably also change the results of available predicates).
So it needn't even do the right thing if they leave it as the default. This is an example of why 'available' is not always what you want. What we want here is 'using'.
I'm still not convinced we are not better off explicitly using the packages that we want with build-deps, rather than having cabal try to work out what versions it thinks we want with all the backtracking and stuff to contend with. It should certainly be easier to implement without using predicates, too.
So I claim that what we're really trying to express is an implication dep:
build-depends: base, (base < 1 `imp` fps >= 0.8)
but then that allows things like:
build-depends: base, (base < 1 `imp` base > 1)
(Not that this dep must be banned, it's just that it's not satisfiable)
My question is: can we find a solution to these kinds of deps in a reasonable amount of time.
Is there any simple restriction we could put on these deps to make solving them easier, eg some monotonicity condition.
I'm more interested in that this allows us to write build-depends: foo, bar build-depends: (foo == 1 `imp` bar == 2) build-depends: (foo == 2 `imp` bar == 1) which is satisfiable in 2 ways if we have all 4 packages and versions available: * foo 1, bar 2 * foo 2, bar 1 neither of which is obviously "better" than the other. Altogether, I think this is another feature which introduces lots of nasty issues that we are better off avoiding. Thanks Ian