Alternative (per-project) package database

Hi, Summarizing my findings (I couldn't find solution to this problem anywhere; maybe somebody else gets interested as well). Experimental setting: A simple package targeting a hello-world like application. We will keep all dependent upon packages in a subdir named .private-pkg All commands are run from within this project directory. Bootstrapping: Initialize packages database ghc-pkg init .private-pkg Clone few initial packages from the existing installation: ghc-pkg describe <package name here> | (GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg register -) These packages are (in this order): ffi, rts, ghc-prim, integer-gmp, base-4.2.0.1 (or whatever base-4 you have) If just "base" is specified, ghc-pkg will attempt to dump the description of base-3.x.x.x package which is not what we need. Check that packages are installed without problems. $ GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg list /home/dima/src/hello-pvt/.private-pkg/ base-4.2.0.1 ffi-1.0 ghc-prim-0.2.0.0 integer-gmp-0.2.0.1 rts-1.0 Try to install some package (for simplicity, choose `bytestring' as it has only base in dependencies). (export GHC_PACKAGE_PATH=`pwd`/.private-pkg/; cabal install bytestring --package-db=$GHC_PACKAGE_PATH --prefix=`pwd`) $ GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg list /home/dima/src/hello-pvt/.private-pkg/ base-4.2.0.1 bytestring-0.9.1.7 ffi-1.0 ghc-prim-0.2.0.0 integer-gmp-0.2.0.1 rts-1.0 Our test executable looks like this: --------------------------------------------------------------------------- module Main where import System.Directory main = do putStrLn "Hello Private World" getDirectoryContents "." >>= putStrLn . show --------------------------------------------------------------------------- So we have to include `directory' as dependency in the project's cabal file. Let's build the executable: (export GHC_PACKAGE_PATH=`pwd`/.private-pkg/; cabal install --package-db=$GHC_PACKAGE_PATH --prefix=`pwd`) Resolving dependencies... Configuring filepath-1.1.0.4... Preprocessing library filepath-1.1.0.4... Building filepath-1.1.0.4... [1 of 3] Compiling System.FilePath.Windows ( System/FilePath/Windows.hs, dist/build/System/FilePath/Windows.o ) [2 of 3] Compiling System.FilePath.Posix ( System/FilePath/Posix.hs, dist/build/System/FilePath/Posix.o ) [3 of 3] Compiling System.FilePath ( System/FilePath.hs, dist/build/System/FilePath.o ) Registering filepath-1.1.0.4... Installing library in /home/dima/src/hello-pvt/lib/filepath-1.1.0.4/ghc-6.12.2 ............................... Building directory-1.0.1.1... [1 of 1] Compiling System.Directory ( System/Directory.hs, dist/build/System/Directory.o ) Registering directory-1.0.1.1... Installing library in /home/dima/src/hello-pvt/lib/directory-1.0.1.1/ghc-6.12.2 Registering directory-1.0.1.1... Configuring hello-pvt-0.1... Preprocessing executables for hello-pvt-0.1... Building hello-pvt-0.1... Linking dist/build/hello-pvt/hello-pvt ... Installing executable(s) in /home/dima/src/hello-pvt/bin .................... $ GHC_PACKAGE_PATH=`pwd`/.private-pkg/ ghc-pkg list /home/dima/src/hello-pvt/.private-pkg/ base-4.2.0.1 bytestring-0.9.1.7 directory-1.0.1.1 ffi-1.0 filepath-1.1.0.4 ghc-prim-0.2.0.0 integer-gmp-0.2.0.1 old-locale-1.0.0.2 old-time-1.0.0.5 rts-1.0 unix-2.4.0.2 Thus, everything needed got compiled and installed under the project's directory. So it will be easy to clean everything up just by removing bin, lib, and .private-pkg subdirs (or choose a better prefix for cabal install, so everything will install in a single location). So, cabal does work in project-private mode. Maybe developers of cabal-install would consider adding such mode to the program, so all these extra options will not be needed. Of course votes from other users will increase the chance of such addition ;) Thanks. -- Dimitry Golubovsky Anywhere on the Web

Hi Dimitry. Depending on what exactly you're after, you may also be interested in Nix and/or NixOS: http://nixos.org/nix/ http://nixos.org/ The Nix package manager builds any package in completely isolated environments and makes sure all dependencies are properly specified. It is easy to build and install one package in many configurations. We have an infrastructure for building Cabal packages easily and quite a number of packages from HackageDB in Nixpkgs (though not as many as Arch). Nix can be used as a secondary package manager on other Unix-like systems. Cheers, Andres -- Andres Loeh, Universiteit Utrecht mailto:andres@cs.uu.nl mailto:mail@andres-loeh.de http://www.andres-loeh.de
participants (2)
-
Andres Loeh
-
Dimitry Golubovsky