Mac OS X Common Installation Paths
The following is my initial e-mail to haskell-cafe about installation paths Mac OS X. I'll clean this up from an e-mail to a proposal soon. MtnViewMark 05:44, 23 December 2009 (UTC)
I have been thinking about the location of installed Haskell package files on Mac OS X. The choice of location affects:
- GHC & other Haskell implementations
- Haskell Platform
- Cabal & cabal-install
If all those agreed on directory locations and layouts, I think the state of Haskell on Mac OS X would be nicer for users. In particular, my hope is for users to end up with an automatically complete Haddock documentation incorporating everything they install.
1) Packages the user installs --global
I noticed that the default location for global installation with cabal is on Mac OS X is /usr/local:
install-dirs global -- prefix: /usr/local
This then intermingles all the Haskell package files along with all sorts of other things that live in /usr/local and environs. While this is arguably convenient for executables that end up in /usr/local/bin (in most people's PATH), it does make things less than tidy, and harder to clean up.
Taking a cue from the various preinstalled language systems on Mac OS X, up over in /Library might be a better place:
- Python puts installed packages in:
- Ruby puts installed packages in:
- Java appears to use
and has a link to the packages that come the framework as:
- Perl put installed packages in:
I suggest that the default place for global installs on Mac OS X be:
Since cabal already by default interposes the compiler version into the lib dir, path, there doesn't appear to be a need to put a <version> dir level near the top.
2) Structure of package pieces
I notice that cabal/cabal-install's default layout of where a package's pieces go, and GHC's layout of its base packages don't agree. Further, cabal/cabal-install's are not set up so that one can easily delete an installed package without hunting down its parts.
cabal/cabal-install defaults the parts as follows:
executables: --prefix--/bin libraries: --prefix--/lib/--pkgid--/--compiler-- data: --prefix--/share/--pkgid-- doc: --prefix--/share/doc/--pkgid--/ html: --prefix--/share/doc/--pkgid--/html
That's at least four directories you need to hunt down if you want to clean out a package, and rummaging through bin to figure out which things to remove. (Not to mention libexec, which isn't used by any packages on my system, so I can't say where it goes...)
GHC/Haskell Platform use a different layout:
executables: --prefix--/bin libraries: --prefix--/lib/--compiler--/--pkgid-- data: --prefix--/share/--pkgid-- doc: --prefix--/share/doc/ghc/libraries/--pkgid--/ html: --prefix--/share/doc/ghc/libraries/--pkgid--/
I think it best if everything for a package is in one place - making removal very easy:
executables: --prefix--/packages/--pkgid--/bin libraries: --prefix--/packages/--pkgid--/lib/--compiler-- data: --prefix--/packages/--pkgid--/share doc: --prefix--/packages/--pkgid--/doc html: --prefix--/packages/--pkgid--/doc
I put the "packages" level at the top, so that other things, like a master Haddock index dir could be put easily directly under the prefix.
3) Symlinks for binaries
This does suggest that it would be nice for the symlink-bindir facility (is that in cabal itself, or added by cabal-install?) to have a version for --global installs. Users could then either set something like:
and then put that in their PATH
4) Quick access to the Framework
I like Java's convenience link 'Home', and suggest that
be a symlink to where the framework's package files are stored:
Other implementations could use the same idea.
Having this here would also (I suspect) help in getting Haddock to be able to find all the bits needed to generate a comprehensive index.
Thoughts? I'd be happy to help by supplying patches for various tools to normalize all this on some agreed upon layout. I admit that I'm a bit unclear where the directory choices are being made: Haskell Platform's build process, or GHC's? Cabal's defaults or cabal-install's? And then clearly parts of Haddock. Given the number of tools that need to agree, seems best that we hash it out (here or in the wiki) first, before making patches.
MtnViewMark 05:44, 23 December 2009 (UTC)