Re: cabal design

Frederik Eaton writes:

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

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