New subject: cabal design

22 Aug 2005

      On Mon, Aug 22, 2005 at 09:08:01AM -0700, Isaac Jones wrote:
...
Frederik Eaton  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/

Re: cabal design

Frederik Eaton

Isaac Jones

Frederik Eaton

Isaac Jones

Frederik Eaton

Duncan Coutts

tags

participants (3)