Re: [Haskell-cafe] install-dirs on Mac OS X
Mark Lentczner wrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
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? 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
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/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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
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. 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/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
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
Re: [Haskell-cafe] install-dirs on Mac OS X
On Mon, 2009-12-21 at 22:55 -0800, Mark Lentczner wrote: 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 Thingtm 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
On Mon, 2009-12-21 at 22:55 -0800, Mark Lentczner wrote: I suggest that the default place for global installs on Mac OS X be: /Library/Haskell/ As I've mentioned I'm mostly an OSX ignoramus. 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. If that's the case then I guess we would also want to do that, but I've no idea how much work that is to support in Cabal (and if it would need any extra package info over and above what .cabal files provide). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
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/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] install-dirs on Mac OS X
Mark Lentczner wrote: 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
Re: [Haskell-cafe] install-dirs on Mac OS X
Mark Lentczner wrote: 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] install-dirs on Mac OS X
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 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/ m...@glyphic.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
