Re: [Haskell-cafe] Re: Hackage on Linux

On 27 August 2010 20:13, Andrew Coppin wrote:

Ivan Lazar Miljenovic wrote:

...

On 27 August 2010 19:13, Andrew Coppin 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.ca... (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@gmail.com IvanMiljenovic.wordpress.com