Configurations proposal

[Ian Lynagh]

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