cabal design

[Frederik Eaton]

On Mon, Aug 22, 2005 at 06:11:11PM -0700, Isaac Jones wrote:
> 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..."

Then please furnish a corrected version. What other option does this
person have?

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

What is the purpose of abstracting differences between compilers?
Isn't it so that users can switch between compilers transparently?
What if a user needs a feature of one compiler which is not present in
another compiler? How would Cabal be hurting him if Cabal let him
access that feature? After all, switching between compilers was never
an option for him in the first place.

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

I'm sorry if I sound frustrated, but I had thought there would be more
of an understanding. However, I resent the manner in which you now
seem to be attacking my comments. There is no need to be ad hominem.
Also, I haven't been trying to hide information from you. It would
have been helpful if you'd asked for clarification earlier on.

So, the whole point of wigwam, and a feature of toast, is to allow
things to be installed in multiple different "roots" ("playpens" in
wigwam). The idea is that you may want to install, say, a web server
and a bunch of its dependencies in one root, so that it can be tested
and deployed in a completely encapsulated and reliable manner. You may
want to test it independently of different versions of the same things
in other roots, or you may want to deploy it side-by-side with an
older version on a front-end server so that it is possible to
seamlessly switch between old and new versions. If all roots share a
package database, then you end up having to give the things which are
installed in those roots separate version numbers in order to keep the
package registrations from overwriting each other. Yet the version
number mapping won't always be injective. You might have packages
which you consider different, yet which have the same version number.
For instance, maybe they are two different revisions from a source
repository, which have the same package version number; or maybe the
same package has been compiled with two different compilers. Both
cases are a common occurrence in QA work, and it would be severely
onerous if people were required to manually insert new version numbers
simply because Haskell package databases were not virtualizable
through Cabal.

Frederik

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