Re: cabal design

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/