On why 'available' is evil
igloo at earth.li
Wed Nov 1 22:50:53 EST 2006
On Wed, Nov 01, 2006 at 02:04:29AM +0000, Duncan Coutts wrote:
> In all this discussion on configurations I think I'm not getting over my
> main point about why we can't go for the 'easy' option of allowing
> package 'available' tests everywhere.
I don't think anyone is arguing that we should do.
> So, 1: it often doesn't mean what you want
> configuration: available(foo >= 2)
> cpp-options: -Denable_cool_feature
> There's no necessary relation between what packages are available in the
> environment and the one(s) that the package is going to be built
> against. So the above will fail if we actually build with foo-1 but
> foo-2 is available.
> What's worse is that it will likely work on the developers machine but
> fail on the users machine.
Am I right in thinking that your objection to removing "using" and
configuration: using (foo >= 2)
default: available(foo >= 2)
build-depends: foo >= 2
build-depends: foo < 2
is that people might incorrectly write something like
default: available(foo >= 2)
and not realise that it can break in some circumstances?
If so then I don't think we should worry about this. They could equally
and not be aware that it will break for some people (e.g. those with foo
1) (OK, in this case they'd probably realise as they've made a #define
for it, but in the need-fps-if-base=1 they could easily not realise).
I don't think "using" is worth the pain just to protect people from
shooting themselves in certain feet. I especially don't think this
should be in the first implementation of configurations as:
* it'll make the implementation take longer to write, as things are
much more complex with it
* it can be added in the future without breaking any cabal files that
have been written, while it can't be removed without doing so
> 2: it allows auto-use deps
> An auto-use dep is one where we add an extra dependency on a package
> just because it's available.
Removing "using" doesn't enable auto-use deps.
> 3: it makes life hard for distros and cabal-get
> So cabal-get needs to figure out the order it's going to install things
> and forward-propagate the set of installed packages at that time to
> figure out if an extra dep on C will be needed or not.
"available" in flags has this problem:
There will be different deps depending on whether bar will be installed
when this package is compiled. I don't see this as a problem as
cabal-get needs to work out what it's going to do before it does it
anyway, or it might compile a dozen packages before hitting a dependency
it can't satisfy and failing.
Whether cabal-get should try alternate orders if the first one doesn't
work is an interesting question, but not one I think we need to worry
about right now.
> 4: it makes the install order significant
Again, having "available" in flags already makes install order
needs baz only if bar is installed first. If you specify all flags it
won't matter, of course.
More information about the cabal-devel