[Haskell-cafe] Re: Hackage on Linux

[Andrew Coppin]

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

Mmm, I suppose...

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

Windows has more package management facilities than most people realise.

For example, go install Office 2007. In fact, just install Excel 2007, 
not the whole thing. Windows Installer can automatically figure out that 
you *do* need to install the Spell Checker (since Excel uses that), but 
you do *not* need to install the Grammar Checker (since only Word and 
PowerPoint use that, and you haven't selected to install those). Not 
only does it decide what to install, but you can query it 
programatically to find out what got installed in the end. And where it 
got installed. And what version was installed. And you can check what 
version of X is installed and do I need to update it with the new 
version of X that I'm packaged with? And is component Y installed? And 
which programs depend on that? Can it be uninstalled if nobody's using 
it now? And...

About the only thing it won't do is automatically grab stuff from a 
central repository. Because, in the Windows world, most software costs 
money. But it really *does* to quite a lot more than people realise. 
(E.g., you can take the installer for Foo-1.0, put the patch file for 
Foo-1.1 next to it, and install Foo-1.1 all in one go, patching the 
original installer on-the-fly as you run it. Ditto for site-specific 
customisations. You can "repair" installed programs, checking whether 
shortcuts still exist, libraries are registered, library versions are 
new enough, file checksums match, etc. And so on.)

>> 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.
>>     
>
> What do you think the "Applications" bit in the definition of Cabal
> is?  (Disclaimer: I haven't read the original proposal).
>   

I'm presuming it was added later, as an afterthought. And that's why 
there's something there, but it doesn't work fantastically well. (E.g., 
Cabal doesn't "know" which binaries are installed, even though it 
installs them. It just wasn't part of the design.)

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

Depends on what kind of establishment you go to, I guess. My uni was 
100% Windows. Only a few servers were Unix (notably the web server). I 
guess it depends on whether you think your students are going into 
datacenter support (probably Unix) or desktop support or application 
development (obviously all desktops are Windows).

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

And, to me, having a real, documented file format would make reading it 
a lot easier. (And *writing* it would become miles easier!) I'm never 
quite sure where one thing ends and another begins. Explicit delimiters 
would help here.

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

I especially love the way that none of Haddock's formatting commands 
seem to work in the Cabal description field, even though everybody keeps 
telling me "it's formatted with Haddock". Most especially, bullet lists 
will not work, no matter what I do, and it's really, really annoying me...

(Haddock is another irritation. It's formatting commands are seemingly 
random and ad hoc. Put something in quotes, and it happily generates a 
link to a non-existent module, without even bothering to check whether 
it exists. Nice...)

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

Unix-style paths are all very well, but if you need to tell Cabal "hey, 
the headers are in C:\Program Files\Headers", then you end up needing to 
type C:\\Program Files\\Headers. Which is unecessary (there's no 
*reason* why it should need escaping, it's just that Cabal is designed 
that way), but I could live with it if it were documented somewhere.

(The fact that you need to twiddle with an existing Cabal package 
description is a whole other kettle of fish, of course...)

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

If you're only trying to _read_ the file, both of these are pretty 
self-explanatory. You only need to worry about the technical details if 
you try to _write_ them. And there are resources across the face of the 
Internet explaining in minute detail everything you could possibly want 
to know. For Cabal's home-brew file format, you've got... the terse 
notes in the Cabal documentation. And that's it.

> So the problem here is a matter of under-specification

Well, the under-specification *is* a problem. I guess for me the main 
problem though is that it's just _ugly_.

> (or possibly
> lack of tool support - including editor modes - for ensuring you're
> doing it correctly).
>   

You know, not everybody uses (or wants to use) Emacs. Other editors 
exist. Besides, I always thought that if you _need_ a special editor to 
edit something, it's not designed very well.

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

Yeah. Just not a very nice one. And one that's supported by only one 
tool in the entire world.