[Haskell-cafe] install-dirs on Mac OS X

wren ng thornton wren at freegeek.org
Fri Dec 25 01:46:28 EST 2009


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


More information about the Haskell-Cafe mailing list