On why 'available' is evil

[Duncan Coutts]

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.

Let me list a few reasons and then expand on them.

     1. it often doesn't mean what you want
     2. it allows auto-use deps
     3. it makes life hard for distros and cabal-get
     4. it makes the install order significant


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.


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. This is bad for a number of reasons. It
means you cannot build a package on one machine and distribute it on
another if that other doesn't have the optional dependency (the only way
to do it would be to delete the optional package on the build machine).

Distros do not support this kind of dep. It mostly makes no sense in
binary-based distros and is actively banned in source distros like
gentoo:

http://www.gentoo.org/proj/en/qa/automagic.xml

Indeed this kind of dependency cannot even be expressed in gentoo's
dependency syntax.


3: it makes life hard for distros and cabal-get

So how is cabal-get supposed to decide before hand all the dependencies
that are needed to install a set of packages.

Suppose we want to install A and B, but B checks if A is available and
if so depends on C.

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.

As I mentioned already, many distros cannot express these kinds of
automatic optional dependencies and so they will have to be turned into
hard dependencies or eliminated by the distro package authors. This is a
lot more work for them than if the translation is straightforward and
can be automated.


4: it makes the install order significant

in the above example, we only need C if we install A then B. If we
install B then A, then we do not need C. So the order that we install
becomes significant. We might be able to make cabal-get always choose
one order (at the expense of preventing parallel builds) but that's not
necessarily the same order that a distro package manager will pick.

This isn't that bad but it's not exactly nice or intuitive.


Duncan