[Haskell-cafe] install-dirs on Mac OS X
Mark Lentczner
GHC & other Haskell implementations
Haskell Platform
Cabal & cabal-install
Haddock
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:
/Library/Python/<version>/site-packages
Ruby puts installed packages in:
/Library/Ruby/Gems/<version>
/Library/Ruby/Site/<version>
Java appears to use
/Library/Java/Extensions
and has a link to the packages that come the framework as:
/Library/Java/Home
Perl put installed packages in:
/Library/Perl/<version>
I suggest that the default place for global installs on Mac OS X be:
/Library/Haskell/
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:
symlink-global-bindir: /usr/local/bin
in .cabal/config.
Or
symlink-global-bindir: /Library/Haskell/bin
and then put that in their PATH
4) Quick access to the Framework
I like Java's convenience link 'Home', and suggest that
/Library/Haskell/GHC
be a symlink to where the framework's package files are stored:
/Library/Frameworks/GHC.framework/Versions/Current/usr/
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.
- Mark (mtnviewmark)
Mark Lentczner
http://www.ozonehouse.com/mark/
ma...@glyphic.com
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Duncan Coutts
> I have been thinking about the location of installed Haskell package
> files on Mac OS X. The choice of location affects:
>
>
> 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.
I just want to say that I think it's great that you're thinking about
this. For Cabal the goal is to do the "Right Thing"tm on each platform,
so if all you OSX people agree what that right thing is then I'm happy
to adjust Cabal's defaults.
Duncan
Heinrich Apfelmus
> 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
> Haddock 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 suggest that the default place for global installs on Mac OS X be:
> /Library/Haskell/
+1
Likewise, ~/Library/Haskell seems to be the best place for user installs.
> 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.
>
> I think it best if everything for a package is in one place - making
> removal very easy
+1
With this scheme, a package could be changed from user to global by
simply drag & drop to the other directory, though that won't work anyway
due to dependencies.
> 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: symlink-global-bindir: /usr/local/bin in
> .cabal/config.
>
> Or symlink-global-bindir: /Library/Haskell/bin and then put that in
> their PATH
+1 , considering that folks may also want to install their GHC with
MacPorts.
Regards,
Heinrich Apfelmus
Tom Tobin
<apfe...@quantentunnel.de> 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/.
Mark Lentczner
> 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/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI
wren ng thornton
> 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:
> /Library/Python/<version>/site-packages
>
> Ruby puts installed packages in:
> /Library/Ruby/Gems/<version>
> /Library/Ruby/Site/<version>
>
> Java appears to use
> /Library/Java/Extensions
> and has a link to the packages that come the framework as:
> /Library/Java/Home
Which is just part of the symlink chain:
/Library/Java/Home
/System/Library/Frameworks/JavaVM.framework/Home
/System/Library/Frameworks/JavaVM.framework/Versions/Current/Home
/System/Library/Frameworks/JavaVM.framework/Versions/<shortVersion>/Home
/System/Library/Frameworks/JavaVM.framework/Versions/<longVersion>/Home
Which is rather convoluted, but is designed to allow switching over the
default Java used internally by OSX. (Java6 is only available on
10.5+intel. And it's not recommended to switch the version registered
for OSX, though it's fine to munge your $PATH to pick the new one since
OSX internals doesn't use $PATH to resolve things.)
Overall, I'd like taking the cue to break things out by version number
and then have some symlinking (or tool) in order to select one of many
installed versions. This would be helpful for people who want to have
multiple versions installed for debugging purposes. Even though the
compiler version is already interposed on the lib dir path, giving a
high-level separation by version makes it easier to deal with the
different sets of libraries compiled by/for each version*compiler.
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. For things used by the system, it's liable to
break the system; and for everything, it's liable to be broken on system
upgrade. OSX does have their framework packaging system, which has been
used successfully in previous versions of GHC; if anything happens in
/Library or /System then it has to go through the framework packaging
system IMO, which means having someone as the OSX maintainer. But I
think the framework system isn't really a great option for the kinds of
development we end up doing. I.e., many Haskell hackers are devoted
developers and many of the packages require other *nix tools to be
installed as well. Because of that, I think it'd be a lot nicer to try
to integrate with the way other *nix installs are done on OSX: that is,
via Fink or MacPorts, or in /usr/local.
Besides, if we used something like a $HASKELL_PATH, or a tool for
querying and recording installation paths, then it doesn't really matter
where the default is since people can choose their own. All that matters
is the structure of the tree rooted there.
> 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.
Again, it's good not to mess with system internals (where GHC is the
"system" here). In general we *want* Cabal to install things in a
different location than the GHC base libraries. Cabal packages can be
upgraded and removed and maybe even have multiple versions installed. If
someone borks their set of Cabal packages, they shouldn't have to
reinstall GHC as well in order to fix things. Similarly, the libraries
used by Cabal itself should be separate from the packages for users to
use. Both GHC and Cabal libraries could be accessible if the user
packages can't satisfy some dependency, but their maintenance should be
kept distinct.
I'm not saying the current Cabal defaults are the best or shouldn't be
changed, but those questions are orthogonal to the issue of interacting
with GHC's base libraries.
> 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.
I would be supportive of a setup with ./packages/<packageName>/ as the
root of <packageName>'s files. This is the strategy used by stow[1], as
well as texmf trees for LaTeX[2]. It works really well for avoiding and
resolving conflicts. There's some development overhead for setting up a
tool for merging the trees, but I think it's worth it (i.e., I'd be
willing to help write it).
The stow approach to tree merging is to symlink everything together into
one canonical directory, but that's not the only option. The texmf
approach is to direct queries through a program which maintains database
information, rather than directing queries through the filesystem. Both
approaches are used by other projects as well. The latter has a higher
development cost, but is ultimately more powerful and configurable.
[1] http://www.gnu.org/software/stow/
[2] http://www.tug.org/tds/tds.html (namely ./tex/latex/<pkg>/* stuff)
--
Live well,
~wren
wren ng thornton
> On Tue, Dec 22, 2009 at 4:49 AM, Heinrich Apfelmus
> <apfe...@quantentunnel.de> 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/.
Seconded.
At the very least, Haskell developers on OSX should be able to choose
between a standard *nix installation scheme and the OSX internals
approach, without breaking anything. The OSX internals approach makes
some amount of sense for folks who just want to run Haskell programs as
end users, but the *nix approach makes a lot more sense for active
developers.
--
Live well,
~wren
wren ng thornton
> 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.
Those languages ---Perl, Python, Java--- are all used internally by the
OSX system itself in order to run startup scripts, maintain the system,
etc. That is, they are provided *by* the system, *for* the system. Users
are free to use them, but they should not alter them in any way.
If you want a newer version of Perl installed, everyone in the Perl
community agrees that it should go into /usr/local or similar.
Overriding the system Perl installation is known to cause issues with
some of the system scripts, often resulting in very obscure kinds of
breakage.
Apple provides a Java6 bundle for OSX 10.5 on Intel CPUs (though Java6
is not available by any other reliable means for any other combination
of versions and architectures). While it is possible to instruct OSX to
switch to using the Java6 bundle for its internal work, this is again
known to cause problems and is highly discouraged.
I'm not as familiar with the use of Python internally, but I'm sure it's
more of the same.
/Library is only for the system to use and for bundle/framework
installs. Thus, if we are to install things there, then the installation
should use the bundle/framework installer.
~/Library is a bit more liberal since that's where all user apps dump
their preferences. But again, ~/Library is intended more for system
stuff and GUI stuff; it's not intended for commandline *nix
applications. There are some tools which cross over between command line
and GUI and they will occasionally put things in ~/Library (e.g., a
couple LaTeX distros) but there are murmurs about that not always
working out so well.
--
Live well,
~wren
Heinrich Apfelmus
> 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
_______________________________________________
Mark Lentczner
> 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.
So I agree, it would incorrect to ever touch /System/Library - and I'm not suggesting that we do. However, it seems completely in line with Apple's intended usage to put things in /Library.
> 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. That is - none of them use Mac OS X's framework system for packages installed by the user. All of them use their native packaging layout. I suggest that we follow suit and use cabal's file layout.
> Overall, I'd like taking the cue to break things out by version number and then have some symlinking (or tool) in order to select one of many installed versions.
As I mentioned, cabal already does this with a per compiler and version subdirectory with the package directory itself. It seems excessive to duplicate it again. The idea from cabal, as I understand it, is that the parts of a package that are not compiler or version dependent are installed only once. Only the compiled lib files are installed multiple times, once per version/compiler.
> Besides, if we used something like a $HASKELL_PATH, or a tool for querying and recording installation paths, then it doesn't really matter where the default is since people can choose their own. All that matters is the structure of the tree rooted there.
For GHC, there is the ghc package system, and that takes care of all this already. And, it doesn't even require consistent package layout (!). So, not matter what we pick here, users will always be able to accommodate personal preference or special situations easily. I don't know about the other Haskell runtimes.
> Again, it's good not to mess with system internals (where GHC is the "system" here). In general we *want* Cabal to install things in a different location than the GHC base libraries.
Yes- that is what I was suggesting. I believe GHC should continue to put it's packages within it's Framework bundle. I was suggesting that cabal installed packages go under /Library.
> Those languages ---Perl, Python, Java--- are all used internally by the OSX system itself in order to run startup scripts, maintain the system, etc. That is, they are provided *by* the system, *for* the system. Users are free to use them, but they should not alter them in any way.
This isn't quite true. It is expected that users will install additional packages for those languages, explicitly for use with the version of those languages provided with the OS. In such cases, the standard place for such installs, is /Library (if made available to all users of the machine, which is the common default for such packages.) Of course the system installed set of packages for such languages are never touched, and live under /System. This is exactly the same state of affairs I'm proposing for Haskell.
- Mark
[*] The Apple guidelines for the /Library and ~/Library files are here:http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI
Mark Lentczner
http://www.ozonehouse.com/mark/
ma...@glyphic.com
_______________________________________________
wren ng thornton
> 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.
[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
> [*] The Apple guidelines for the /Library and ~/Library files are here:http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI
Thanks for the link. I followed through to a couple of other links that broadly
support your position:
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?
I'm pleased to see this issue is getting some serious consideration: I haven't
actually used Haskell for a while, and since I last did I've switched to using a
Mac for much ogf my development, so when I return to the Haskell fold it will be
nice to have the system play nicely with the host environment.
#g
wren ng thornton
> Mark Lentczner wrote:
>> [*] The Apple guidelines for the /Library and ~/Library files are
>> here:http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI
>>
>
> 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/BPFileSystem/Articles/LibraryDirectory.html
>
>
> [2]
> http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/Domains.html
>
>
> 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
Yitzchak Gale
> I have been thinking about the location of installed Haskell package
> files on Mac OS X.
Thanks, we've really needed that for a while now.
> The choice of location affects:
> � � � �GHC & other Haskell implementations
> � � � �Haskell Platform
> � � � �Cabal & cabal-install
> � � � �Haddock
> ...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.
There is more than just the version. There are (or have been in the
past) a number of different "standard" methods of installing GHC on
Mac OS X, each serving its own purpose, including:
o Haskell Platform
o GHC-HQ binary installation tarballs
o Manuel's app bundles
o Builds from source
o MacPorts
o Fink
At times, I have needed several of them to exist independantly
on my machine at once at the same GHC version.
Even for those who never need more than one of those
at once, it could wreak havoc if one installs on top of the other.
In your plan, how do we distinguish those methods?
Thanks,
Yitz