cabal design

[Isaac Jones]

Frederik Eaton <frederik at a5.repetae.net> writes:

> 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

No, that's not the proposal document.  

It's in the "old" links of the web page.  It used to be on the front
page, but I recently moved it, which I forgot about, since it's not
really necessary anymore.  You could have found it if you googled for
"cabal proposal" though.

> Looks good.

Thanks.

The wiki page was superseded by the proposal document, but wasn't
really maintained much anyway, as I mentioned.

>> (about adding a --package-conf= flag to cabal):
(snip)
>> > 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. 

I have looked at these tools.  I looked at toast some time back.  Can
you explain what's broken about the toast / cabal integration?  Looks
to me like cabal was integrated with toast in May and it took about 10
lines, but maybe it's broken because of what you're talking about?

> Read the wigwam page especially.

Honestly, I don't see the problem.  Can you please explain it to me?

> 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!

I don't understand this part.  Cabal packages can be installed in
arbitrary locations.

(snip)

>> > 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

So far, I don't think you've every been right when you start a
sentence with "so you're saying..."

> 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?

We have added features to cabal that only make sense with particular
compilers, for instance, some compiler extensions.  One of Cabal's
main goals is to abstract the difference between compilers.  To the
extent that it does not do so it fails at this goal.  So when someone
asks for a feature, I try to figure out how to make it generic among
compilers, and I work with the users, as I'm working with you, to
understand their requirements so we can maintain compatibility and
keep users happy at the same time.

> 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 problem is that you keep demanding a particular implementation of
a feature instead of just explaining a use case.  (Another problem is
that you're being rather rude about it.)  Honestly, I don't want to
read in detail about toast and wigwam and try to guess what the
problem is.  It's definitely not as obvious to me as it is to you.

Please take a few minutes and just explain the use case.  I promise
that it'll be more constructive than your demands and snide remarks.


peace,

  isaac