Where should cabal install to by default?
Manuel M T Chakravarty
chak at cse.unsw.edu.au
Wed Aug 6 07:03:07 EDT 2008
> On Mon, 2008-08-04 at 11:56 +1000, Manuel M T Chakravarty wrote:
>> Just some random remarks:
> Thanks for the useful feedback on OSX conventions. I was unaware about
> several of them.
Also have a look at
In particular, it says
If your software is multi-platform, try to accomodate your Mac OS X
by not using /etc, /usr/local, and so on, unless your software is
accessible via the command-line.
So, the appropriate install location is also dependent on the type of
>> * Hiding installed files in a . directory is very bad style IMHO. I
>> think that should never happen.
> Just on OSX or on Unix too? On Linux I'm not sure where else we could
> put things that's per-user. People seem to object strenuously to
> programs automatically putting files in any dir other than ~/.progname
> (or one or two other .files established by specification or
I think an installer is in a somewhat special situation here. It's
not that creating files is a side-effect that the user doesn't care
about. Installing files is the primary purpose of an installer. And
whenever programs are to automagically appear in the PATH, you either
have to modify the contents of one of the directories in the PATH or
you have to alter the PATH setting (which is worse).
>> Independent of whether you install right into /usr/local/bin or
>> whether you symlink or whatever. You might install files
>> under /usr/local/lib/cabal and then symlink, but probably its nicer
>> installto /usr/local/lib/<package>-<version> and then symlink.
> For global installs we use prefx=/usr/local at the moment, so that
> mean /usr/local/lib/<package>-<version> for libs and /usr/local/bin
> for binaries. I've just implemented the symlinking feature so we could
> change the default on global installs to use the version suffix on
> binaries and symlink back into /usr/local/bin.
> Or do you mean we should install binaries
> into /usr/local/lib(exec?)/<package>-<version> and then symlink
> into /usr/local/bin. That would also be reasonable I suppose, though
> then the versioned binaries are not on the path.
I'd prefer to only put symlinks into /usr/local/bin or similar. It
makes it easier to remove things. You can still put symlinks to
versioned binaries there. (That's what the Mac OS installer for GHC
does, for example.)
>> * On OS X, its not generally appropriate to install into /usr/local
>> either. Each user has ~/Applications and ~/Library directories that
>> are usually used for per-user installs. Just generally using sudo
>> put binaries into /usr/local is also bad because not every user will
>> have admin rights on the machine.
> Oh, great. I didn't know OS X had a standard location for per-user
> installs. That's excellent. So is there a preferred layout for those
> dirs? I'm guessing there probably is.
OS X has this concept of bundles. The idea is that all installes that
come with an application are in one directory (instead of scattered
across the system). So, in /Applications and ~/Applications, there is
just one dir per app. Applications that need to store data, do that
in again just one dir under ~/Library and they may have another dir
with preferences under ~/Library/Preferences.
For example, the version of Emacs I am using, AquaEmacs, uses ~/
Library/Preferences/Aquamacs\ Emacs instead of .emacs.
>> * ~/.cabal is bad on Mac OS, too. Preferences ought to go into ~/
> Ok. BTW, in that case we should probably fix
> System.Directory.getAppUserDataDirectory to follow the system
> on OSX. Currently it uses $HOME/.appname on all unix systems (and the
> Windows convention on Windows). If necessary we may want to
> split getAppUserDataDirectory into a variant for config and another
> Since cabal-install is a program should it still be
> using ~/Library/Preferences/ or is there are
> corresponding ~/Applications/Preferences/ ? Where would be
> appropriate for cabal-install put its download cache and build logs?
There is no ~/Applications/Preferences, only ~/Library/Preferences.
However, to be fair, some command-line applications with a Unix origin
use '.appname' (eg, ghc).
More information about the Libraries