[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