Re: cabal design

On Mon, Aug 22, 2005 at 06:11:11PM -0700, Isaac Jones wrote:

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

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/