[Haskell-cafe] Re: Hackage on Linux

[Ivan Lazar Miljenovic]

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

But that's one specific installer; not a generic package management
system (in terms of the extra sub-dependencies).

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

I've never seen this Foo-1.1 behaviour, unless it's a specific
patch-level installer that uses the same data.  Note also that this
isn't automatic: you have to explicitly download Foo-1.1 yourself,
etc.

So, to be more specific, we can state that Windows has a form of
package management, without an actual package management _system_ such
as typically found in Linux distributions.

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

Ummm, Cabal is a combination of a build system and metadata
specification for packages; it isn't a package management system or
even a package manager (hence my previous link to my blog post).  As
such, it isn't designed to keep track of installed applications, and
the only reason it knows which libraries are installed is because
ghc-pkg can tell it so it knows which dependencies are already present
without needing to install them again.

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

Oh really?

And yes, the unis I've been at have overall had Windows-based desktops
everywhere (with the occasional Macs, especially in biology), but the
IT/CS departments had Linux/Unix machines (at UQ, desktops were
primarily Windows but with an outdated Solaris server which people
remotely connected to; at ANU the CS department has Ubuntu everywhere,
even for student machines).  This is also true in some non-IT/CS
departments (at UQ, the math department provided the option of
installing Fedora on the academic's machines, but not many took up
that offer and preferred to ssh in to the dedicated machines; then
again, UQ had just switched to using an Exchange-based system for
email, calendaring, etc. ...).

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

Sure; this is a matter of under-specification of the file format.  I
would point out what happened with X configuration recently: they went
from an ini-style configuration file that was relatively human
readable and editable (especially if you were basing your config off
of a guide) to an XML-based one when they switched to HAL-based device
management (since XML is easier for programs to read and write) and
back to the original format because the XML-based format was a
disaster.

I personally find a file format such as Cabal's much easier to read
and write than one that requires me to put a whole bunch of angled
brackets in everywhere...

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

I've done bullet lists; it requires a slight change to the usual:
http://hackage.haskell.org/packages/archive/graphviz/2999.10.0.1/graphviz.cabal
(note the `.'s in between lines).

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

Oh, I definitely agree with you that Haddock's markup leaves a lot to
be desired.

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

Huh, I was under the impression that you could just use unix-style
file paths in a relative fashion with Cabal even on Windows...

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

And looking up other .cabal files... ;-)

Then again, even if we used XML or JSON we'd still have to look up
what the write tag-names, etc. are.

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

Did I say Emacs?  Don't other editors/IDEs/etc. have the ability to
syntax-highlight various files, generate code, etc.?

And whatever editor you use to edit Haskell code with, whilst you
could write Haskell code in Notepad, etc. isn't it easier using an
editor with at least syntax highlighting?

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

Well, which other tools need to support it?

And from a brief bit of Googling, Ruby Gems seems to use its own
(YAML-based) file format...

Now, Duncan et. al. are working on Cabal-2; it's quite possible that
they're taking complaints like this into account, but I would much
prefer to keep something like the current format (but with better
specifications) than one using XML or JSON.

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