Mark Lentczner wrote:
First, we must look at how Apple intends the various Library directories to be
used. Please see the Apple docs on it[* link below]. Essentially, /Library is
the Mac OS X equivalent of /usr/local.
However, I would be opposed to storing anything in /Library or /System. Those
are for system use and sysadmin experience tells me never to mess with the
system installs.
You are only partially correct. /System/Library is for system installed pieces
(those that come with OS X), /Library is for things that are available system
wide, but have been installed after the OS, by the user. In particular, if you
install Perl packages that don't come with OS X, they will end up in
/Library/Perl. The same is true for Python and the other languages. /Library
is the same place all sorts of user installed things go: MySQL components,
video decoders, printer drivers, just to name few. Basically, anything that the
user installs and expects to be available to all accounts is put there.
I have read the docs and have been a Mac (both OSX and Classic)
developer for years. I haven't done any system hacking with Haskell, but
I've done plenty with Perl, AppleEvents, and so forth. Yes, /System is
for the system itself and forbidden to touch; /System/Library is for
system components that would usually go into / or /usr; and /Library is
for stuff that usually goes into /usr/local, /usr/share, or /opt which
can blur the line between "system" and "local".
If you install new Perl modules using the cpan that's in /Library, then
naturally it's going to install things in /Library (where else would it
put them?). But, as I've said, the OSX Perl community agrees that using
the cpan that comes in /Library is a bad idea. If you upgrade the
modules which ship with the OSX system you can break things. Depending
on the module in question you can break things enough to require
reinstallation or reverting to system backups. Therefore the OSX Perl
community advocates installing your own version of Perl and cpan in
order to avoid altering the system installation. Since Haskell is not
used internally by OSX we're not susceptible to the same upgrade
problems as Perl and Java are, but that doesn't mitigate the danger of
altering the system installations for Perl or Java.
All that said, I stand by my position. In addition to being a Mac
developer I've also been a sysadmin for a number of different flavors of
*nix, again for years. This is not a question of how other communities
install their tools, it's a question of what the proper method is for
installing Haskell tools.
if anything happens in /Library or /System then it has to go through the framework packaging system IMO,
This is not a requirement of /Library at all, and NONE of the other language
systems on Mac OS X follow it.
No, it is not a requirement of Apple. It is a requirement of *me*. As an
active developer and administrator, I will not install anything into
/Library which does not use the bundle/framework packaging system. This
restriction eases maintenance, backup, and deployment strategies. This
isn't the place to argue about system administration, I'm simply
pointing out my experience both for *nix in general and for OSX in
particular. Duncan said he didn't know much about OSX particulars and I
think you are providing an incomplete (or, IME, inaccurate) perspective
of how development is managed on OSX.
Again, this is not a question of how MySQL, video codecs, or printer
drivers are handled by other communities who may or may not have a
cohesive development community; it's a question of how the Haskell
toolchain should be managed by the particular community of Haskell
developers we have. In my experience with other development communities
on OSX ---Perl and Java--- there is strong resistance against touching
/Library. Since many Haskell packages require access to third-party C
libraries, Haskell developers must already have some mechanism for
handling *nix installations. I haven't used MacPorts, but Fink
explicitly installs things into /sw in order to ensure non-interference
with the system. There are similar reasons why people use /opt instead
of /usr/local on *nix systems, and why the CAT[1] (to pick a former
employer) uses their own /pkgs directory for managing installations.
Given this very unixy environment for the libraries which Haskell code
will be linking against, using /Library seems disingenuous as well as
liable to introduce confusion for those less familiar with OSX
internals. Given the strong core of *nix developers and the unixy nature
of Haskell development on OSX, I see no appreciable reason for
distinguishing OSX from other *nices. The only exception would be for
providing frameworks so that non-developer end-users can obtain the
necessary tools for playing Haskell games or running Haskell programs
without knowing anything about what goes on under the hood. Again, in
the past GHC has been available via frameworks so this is nothing novel.
GHC is also available via Fink for developers who want a stable/old
version, so treating OSX like any other *nix is again nothing novel.
My point in raising $HASKELL_PATH or a tool with equivalent force was an
attempt to move this discussion towards a more fruitful direction.
Obviously we disagree about the default location for installing the
Haskell toolchain, but that disagreement is clouding what I think is the
more important issue you raised, which is also relevant to non-OSX
developers. Regardless of where we put it, I think it is worthwhile to
develop a canonical organization for the entire Haskell toolchain such
that specifying a $HASKELL_PATH is sufficient to locate all the
auxiliary files for Hoogle, Haddock, Cabal, compilers, etc.[2] Such an
organization would be similar in spirit to the TeX/Metafont Directory
Structure used for the TeX, LaTeX, BibTeX,... toolchain. This in turn is
similar to Perl's CPAN organization, though much of the work CPAN does
is already handled by Cabal and GHC's package system. Where
$HASKELL_PATH is located may vary by OS or by computer, but that's a
side issue. Having a canonical organization under that directory would
be beneficial for all *nices (and maybe Windows?) and seems less
predisposed to religious disagreements about how complete system
installations should be maintained.
[1] https://www.cat.pdx.edu/
[2] Executables, manpages, and other standard *nix files should be put
in standard locations. Since *nix uses $PATH, $MANPATH, etc to handle
the merging of multiple "standard location" trees, I think the structure
under $HASKELL_PATH should support /bin, /man, etc in case people want
to keep their Haskell stuff together. Ideally though, the Haskell
directory structure should not require those directories, since doing so
would interfere with using other package management systems like Fink
for managing complete system installations. I.e., we don't want to take
on the role of native packaging systems, but we should be amenable to
non-native packaging systems as well.
--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
