[Haskell-cafe] Re: Hackage on Linux

[Ivan Lazar Miljenovic]

On 27 August 2010 19:13, Andrew Coppin <andrewcoppin at btinternet.com> wrote:
> 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.

Well, what happens if you have a university account where GHC is
installed on the machines (and it's actually recent enough, something
my uni doesn't have so I install GHC into my home directory) or other
multi-user environments?  You may wish to use extra packages than what
are available by default.

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

Whilst this isn't applicable to Windows, in systems with a proper
package manager, you get dependencies brought in for you as well.

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

What do you think the "Applications" bit in the definition of Cabal
is?  (Disclaimer: I haven't read the original proposal).

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

And GHC was designed with a POSIX-style environment in mind.  And
realistically, Windows is the only major non-Posix like OS nowadays.

Furthermore, GHC was aimed primarily at teaching and research, and
from my (admittedly limited) experience the IT/CS departments at unis
tend to run Unix/Linux.

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

Because I'd like to read what a package is about from its .cabal file:
Cabal isn't just a build system specification, it also provides medata
on the project in question.

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

Do you mean in the description field, etc.?  That's because it uses
Haddock for that to put it on Hackage (admittedly yes, that isn't
documented and I got caught out by that as well; however that only
seems to matter if memory serves when displaying the formatted output
on Hackage).

Otherwise, if you mean actual file paths when specifying extra files,
etc. then that's because it uses Unix-style paths.

> Now if this were XML or JSON, everybody would already *know* the escaping
> rules.

Except for people that have never used XML or JSON... don't we count?

(OK, I lie, I have used XML, and I'm trying very hard to forget it.)

> 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?

So the problem here is a matter of under-specification (or possibly
lack of tool support - including editor modes - for ensuring you're
doing it correctly).

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

... except this "home grown thing" _is_ a file format.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
IvanMiljenovic.wordpress.com