cabal design

[Frederik Eaton]

On Mon, Aug 22, 2005 at 09:08:01AM -0700, Isaac Jones wrote:
> Frederik Eaton <frederik at a5.repetae.net> writes:
> 
> > If there have been a lot of discussions and decisions, I don't think
> > that mailing list archives, or wherever the analysis is located, are a
> > good repository for design documents. I believe (and I'm not saying
> > you disagree at this point) that things which are planned and which we
> > want people to potentially help out with should go on the wiki, along
> > with their rationale.
> 
> We wrote and maintained a proposal document.  It's on the web page.

Oh, this?: http://www.haskell.org/hawiki/LibraryInfrastructure
Looks good.

> (about adding a --package-conf= flag to cabal):
> >> (snip)
> >> >> In a way, the problem isn't "lack of support" but a different model of
> >> >> finding packages... It's not like a compiler extension that one system
> >> >> supports and one doesn't; this flag breaks abstraction between
> >> >> compilers in a way that --in-place does not.  I haven't heard any use
> >> >> cases where --in-place won't work.
> >> >
> >> > Well, we're talking about two different features here. 
> >> 
> >> I'm talking about use cases, not features :)
> >
> > We're talking about two different use cases.
> >
> >> > I want to be able to specify an arbitrary location. You want to be
> >> > able to specify the current working directory. Not the same thing,
> >> > is it? I think it should be possible to specify an arbitrary
> >> > location, at least for ghc.
> >> 
> >> Since this breaks abstraction, I would prefer to avoid this until I
> >> see a convincing use case.
> >
> > I thought I already gave one: http://toastball.net/toast/
> > Here's another: http://www.wigwam-framework.org/doc/overview.html
> 
> Those aren't use cases.  Can you please explain a situation where
> --in-place doesn't work, and --package-conf= is required?

Did you look at these tools? In order to use cabal packages with them,
you'd have to be able to specify arbitrary package databases for each
package. People have good reasons for doing so. Read the wigwam page
especially. If cabal packages can't be installed in arbitrary
locations, then not only will this be an serious pain in the ass for
some special users - which should be enough of a reason on its own! -
but it will rule out using Haskell in the server infrastructure of
certain large software companies. I worked at Yahoo which doesn't use
wigwam but uses something similar; I'm sure other places are moving or
have moved in the same direction. Writing off these groups is surely a
bad idea!

Achieving this modularity with your --in-place suggestion, as I
understand it, would require specifying a separate -package-conf
option per package (or directory of packages, when that becomes
allowed) per ghc invocation, at which point one would be hard pressed
to call the things "package databases" since they will mostly contain
one package each. Cabal would thus be forcing users to re-implement
their own package database; plus, it would still require an interface
to let them specify the package database locations, so nothing gained
...

Note that any compiler that has a notion of packages is going to have
a notion of a package database, whether it is a file or a directory or
a search path of directories or a network server. It's where we go to
find packages. All I'm saying is that this needs to be virtualizable.
Cabal needs to let users specify it, whatever it is.

> > But let's think about what you're saying. You don't want to break some
> > abstractions in your implementation, so you're causing the abstraction
> > that you are supposed to be providing your users with to break. 
> 
> Of course that's not what I'm saying.  I still seen a use case where
> --in-place won't work.
> 
> Here's a general rule I follow when making decisions about cabal: If I
> have two possible features, but only one use-case, and feature number
> 1 covers that use-case just as well as feature number 2, and feature
> number 1 maintains abstraction between compilers, whereas feature
> number 2 breaks it, then I choose feature number 1.
> 
> That is, try to find a way to solve the users' problem without
> breaking the abstractions between compilers.

To be sure, there is a trade-off between generality and practicality.
However, I think you're failing to be general enough in the design of
Cabal. Since it's going to be so widely used, we want to come up with
an interface which won't have to change much, and this will require
something which is more general than usual. However, there are valid
use cases to support my argument for greater abstraction. Please let
me know if there is still confusion over the use cases I've been
presenting.

> > We need to be able to deal with packages getting installed anywhere
> > and everywhere and every which way. Everything about the
> > installation of a package needs to be virtualizable.
> 
> I disagree.  When you write a common interface on top of multiple
> implementations, you sometimes lose control over the details of the
> implementations, but the interface remains useful because it is
> consistent and nevertheless powerful.  If you want control over every
> aspect, then you can drop down to the implementations and use them
> directly.

So you're saying that someone who needs a particular level of
abstraction from cabal should rewrite the build systems of all the
packages that they intend to use, rather than asking Cabal to harbor a
certain feature, if that feature is one which might only be supported
when Cabal is used in conjunction with ghc?

That's ridiculous. We have to look forwards, not backwards. We can't
just restrict ourselves to the lowest common denominator of all
compilers, or we won't go anywhere.

Keep in mind that Cabal exists to serve its users, not the other way
around.

> > The package database should not be tied to the user or the system or
> > the compiler version.
> 
> There's really no way around that.  Each compilers' binary format
> differ.

That's not what I meant. With ghc, there is a default package database
which depends on the user and the compiler version. But you can
specify a non-default location as well. Cabal should provide an
interface which allows you to access this feature.

Frederik

-- 
http://ofb.net/~frederik/