On Tue, Dec 22, 2009 at 4:49 AM, Heinrich Apfelmus wrote:

Likewise,  ~/Library/Haskell  seems to be the best place for user installs.

While I don't mind the /Library/Haskell path for global installs, I'm not sure how I feel about this for local installs. It usually drives me crazy when my more "Unix-y" tools stick stuff in my ~/Library/ directory; for instance, I had to actively fight with my copy of Aquamacs Emacs in order to get everything running from ~/.emacs.d/ rather than ~/Library/Preferences/Aquamacs Emacs/.

Tom Tobin wrote:

Heinrich Apfelmus wrote:

...

Likewise, ~/Library/Haskell seems to be the best place for user installs.

While I don't mind the /Library/Haskell path for global installs, I'm not sure how I feel about this for local installs. It usually drives me crazy when my more "Unix-y" tools stick stuff in my ~/Library/ directory; for instance, I had to actively fight with my copy of Aquamacs Emacs in order to get everything running from ~/.emacs.d/ rather than ~/Library/Preferences/Aquamacs Emacs/.

The reason I'm proposing this is consistency: the idea behind the two Library folders is that your Haskell installation is the union of the /Library/Haskell and the ~/Library/Haskell directories. The only difference between these two directories should be that the former is available to all users while the latter is available to just a single user. On a related note, with the --prefix--/packages/ layout for packages in place, it would ideally be possible to mv packages from /Library to ~/Library and vice-versa, making them available to all users or to just a single user with a simple file rename. At least, that's the OS X philosophy. Our main obstacle would be to figure out what to do with dependents and dependencies. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

On Dec 22, 2009, at 12:35 PM, Duncan Coutts wrote:

One thing I think I've seen said before however is that things in /Library and ~/Library are supposed to be app bundles or frameworks or some other special OSX packaging thing, rather than traditional Unix-style installations.

Nope - not true. There are all sorts of things under the Library directories. Again, note the list of other languages that store things under /Library. In those cases, those systems are storing installed packages in just the normal way they would on Linux or other unix systems. On Dec 22, 2009, at 11:49 AM, Tom Tobin wrote:

It usually drives me crazy when my more "Unix-y" tools stick stuff in my ~/Library/ directory; for instance, I had to actively fight with my copy of Aquamacs Emacs in order to get everything running from ~/.emacs.d/ rather than ~/Library/Preferences/Aquamacs Emacs/.

I don't know the details, but that sounds inappropriate. If there is no graphic UI for such settings, then ~/Library/Preferences is the wrong place. Apple guidelines[*] are that users should generally not have to poke into ~/Library for normal tasks (such as editing their preferences). As for Haskell, I would suggest that ~/.cabal/config continue to be the location of the user configuration file. Only the installed packages themselves, if installed "--user", would go into ~/Library - since these are files users don't edit or alter once installed. Of course, you'd still be free to easily reconfigure the location back to under ~/.cabal if you like, since those entries would still be in config for your editing, and ghc-pkg doesn't, thankfully, actually care where things are, once told. On Dec 22, 2009, at 2:49 AM, Heinrich Apfelmus wrote:

+1

Excellent. Since there seems to be somewhat an interest in working this out, I've set up a wiki page: http://www.haskell.org/haskellwiki/Mac_OS_X_Common_Installation_Paths - Mark (mtnviewmark) [*] The Apple guidelines for the /Library and ~/Library files are here: http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFil... Mark Lentczner http://www.ozonehouse.com/mark/ mark@glyphic.com

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

Graham Klyne wrote:

Mark Lentczner wrote:

...

[*] The Apple guidelines for the /Library and ~/Library files are here:http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFil...

Thanks for the link. I followed through to a couple of other links that broadly support your position:

[1] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFil...

[2] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFil...

But, on reading [1], I also see "Although an application can use this directory [/Library] to store internal data or temporary files, it is not intended for storage of the application bundle itself or for user data files. Application bundles belong in an appropriate /Applications directory, while user data belongs in the user’s home directory."

This makes me question whether /Application might be the appropriate place?

/Applications is typically for GUI applications as opposed to commandline programs. Though again, there are a few examples of toolchains which cross that boundary and use /Applications (e.g., TeX Live). Commandline apps which are deemed sufficiently GUI tend to go in /Applications/Utilities which is another option (not that Haskell really belongs there). -- Live well, ~wren