[Haskell-cafe] Re: Hackage on Linux

Andrew Coppin andrewcoppin at btinternet.com
Fri Aug 27 05:13:07 EDT 2010


Simon Marlow wrote:
> If you look at the original Cabal design document[1], you'll see that 
> one of the goals of Cabal was to be the glue that lets you convert an 
> arbitrary Haskell library into a native package for a variety of 
> systems - including MSIs on Windows.  Indeed, I must admit when we 
> were designing Cabal I thought that native packages would be the most 
> common way that people would install Cabal packages, specifically 
> because many systems already have a good package manager, and trying 
> to bypass the system package manager would be a fundamental mistake.  
> It turned out that cabal-install would be a lot more useful than I 
> imagined, but the two systems are complementary: native packages are 
> for installing globally, and cabal-install is for installing packages 
> in your home directory.

Why would you ever want to install a package per-user? I mean, if you 
don't have permission to do a global install, then you also don't have 
permission to install GHC in the first place so...? Indeed, the *only* 
plausible reason I can think of is if you're trying to build something 
that has unusual package version constraints, and you want to build it 
without upsetting the entire system.

> Even on systems without a package manager (i.e. Windows), it would 
> make more sense when installing a package globally to build an MSI 
> first, so that the system can track the installation and let you 
> uninstall it later.

I did have a look at building a binary installer using Nullsoft NSIS. 
Unfortunately, I don't know of any tool in existence that can build MSI 
files that isn't absurdly expensive. (E.g., InstallShield is ~£4,000, 
which is extortionate for a program that just copies files around. Even 
BackupExec isn't *that* expensive, and that's mission-critical!)

Of course, *I* was looking at NSIS specifically for installing 
Haskell-to-C bindings. These are virtually impossible to build on 
Windows, and I figured if I could build such a package once, I could 
then make a binary installer out of it and never again have to build it 
from source. (Until the next GHC version, anyway.) But I utterly failed 
to make the building part work, so I never got to the next bit.

If you were to use binary installers for regular Haskell packages, the 
only real benefit would be that you can now UNinstall them again. It 
might be worth doing that, and it looks plausible that you could 
automate it...

> [1] http://www.haskell.org/cabal/proposal/

Interesting. So Cabal was never intended to handle executables at all. 
(The entire proposal speaks only about *libraries*.) Suddenly several of 
Cabal's deficiencies make a lot more sense. It doesn't handle 
executables properly because it was never designed to. It doesn't 
uninstall because Cabal packages are supposed to be converted into real 
packages first, and real package managers provide uninstall 
capabilities. And so on.

It's slightly disturbing how the proposal meantions "make" every three 
sentences. You realise that make only exists under Unix, right? There 
_are_ other operating systems out there...

I also can't for the life of me work out why something *designed for* 
automatic processing is designed without machine-readable syntax. Even 
in this early proposal, Cabal is already using that horrid ad hoc 
undocumented file format that only Cabal itself can actually parse and 
understand. Why not XML or JSON or *something* with a formal spec and a 
wide range of available tools? It makes no sense at all. And in case 
somebody is sitting there thinking "It IS documented. It's simple, isn't 
it?", did you know that file paths have to be escaped like Haskell 
string literals? No, I bet you didn't. Where is this fact documented? It 
isn't. Why was this decided? I'm guessing it's an implementation 
accident rather than a deliberate decision. Now if this were XML or 
JSON, everybody would already *know* the escaping rules. And we'd have 
tools that know about these rules and can handle processing such files. 
People seem to think that Cabal's existing format makes it easier for 
humans to read and write, but personally I'm always left wondering 
exactly which constructions are or aren't permitted. Can I put several 
values on a line here, or do they have to be seperate lines? Do all the 
field values have to be indented by the same amount? How does Cabal 
figure out which fields are subfields anyway?

In summary, I would be *so* much happier if we had a real file format 
rather than this ugly home-grown thing. Unfortunately, this would break 
everything on Hackage, so it will never be fixed.

> [2] http://www.haskell.org/pipermail/cabal-devel/2007-August/000740.html

Also interesting. I've never heard of WIX before...



More information about the Haskell-Cafe mailing list