Duncan Coutts:
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 http://developer.apple.com/tools/installerpolicy.html In particular, it says If your software is multi-platform, try to accomodate your Mac OS X users by not using /etc, /usr/local, and so on, unless your software is only accessible via the command-line. So, the appropriate install location is also dependent on the type of application.
* 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 convention).
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 to 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 and 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 ~/ Library/Preferences/
Ok. BTW, in that case we should probably fix System.Directory.getAppUserDataDirectory to follow the system convention 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 for data.
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). Manuel