Ivan Lazar Miljenovic wrote:
On 27 August 2010 19:13, Andrew Coppin <[email protected]> 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.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
