From mboxrd@z Thu Jan 1 00:00:00 1970 From: Federico Beffa Subject: Re: [PATCH 0/2] native-search-paths for GHC Date: Wed, 7 Oct 2015 18:07:33 +0200 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjrFf-00018f-V7 for guix-devel@gnu.org; Wed, 07 Oct 2015 12:07:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjrFe-0007Xp-Sh for guix-devel@gnu.org; Wed, 07 Oct 2015 12:07:35 -0400 Received: from mail-vk0-x232.google.com ([2607:f8b0:400c:c05::232]:35678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjrFe-0007Xg-Ld for guix-devel@gnu.org; Wed, 07 Oct 2015 12:07:34 -0400 Received: by vkao3 with SMTP id o3so14328362vka.2 for ; Wed, 07 Oct 2015 09:07:34 -0700 (PDT) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: ericbavier@openmailbox.org Cc: Guix-devel ericbavier@openmailbox.org writes: > From: Eric Bavier > > The first of these patches lets search-path-as-list function correctly when a > pattern is given and the 'directory file type is specified. > > The second adds a native-search-paths field to our ghc package. It modifies > our haskell-build-system to install a package-specific package database with > each haskell library. GHC insists on a binary package cache file called > 'package.cache' to be in each directory listed in GHC_PACKAGE PATH, so we > uniquely name the package database directories, and use a file-pattern to add > those to GHC_PACKAGE_PATH. > > The benefit of this over the current situation is that one gets the benefit of > `guix package --search-paths`. Currently, after installing ghc packages, the > user needs to know to manually add > ~/.guix-profile/lib/ghc-7.8.4/package.conf.d to their GHC_PACKAGE_PATH. GHC > package recipes would no longer need to propagate runtime dependencies, and > 'guix environment' also works nicely out-of-the-box:: > > $ guix environment --ad-hoc ghc ghc-attoparsec > $ ghc-pkg list > /gnu/store/...-ghc-mtl-2.1.3.1/lib/ghc-7.8.4/ghc-mtl-2.1.3.1.conf.d > base-4.7.0.2 > ghc-prim-0.3.1.0 > integer-gmp-0.5.1.0 > mtl-2.1.3.1 > rts-1.0 > transformers-0.3.0.0 > /gnu/store/...-ghc-regex-base-0.93.2/lib/ghc-7.8.4/ghc-regex-base-0.93.2.conf.d > array-0.5.0.0 > base-4.7.0.2 > bytestring-0.10.4.0 > ... > /gnu/store/4vvmngz1w8ccm7v7mk4f4dxk45834464-ghc-attoparsec-0.13.0.0/lib/ghc-7.8.4/ghc-attoparsec-0.13.0.0.conf.d > array-0.5.0.0 > attoparsec-0.13.0.0 > ... > > Though, as you can see in this example, libraries may be listed more than > once. As far as I can tell at this point, that is just an aesthetic detail. > > Future work might involve filtering build-only library dependencies from the > generated package database. We could probably also remove the ghc package > database creation during profile generation. > > I'd be insterested in hearing others' thoughts on this approach. Hi Eric, sounds like a good approach to work around the "package.cache" clash. I have a couple of questions: * If I understand correctly, the configuration files of dependencies are copied in a unique directory for each package. Instead of copying would a symlink work? (There are literally thousands of packages on Hackage and hopefully Guix will get more of them.) * Some Haskell libraries have a rather large list of dependencies. For this reason I can imagine that in some situations GHC_PACKAGE_PATH could grow rather long. This thought made me wonder if there is a maximum length to the value of environment variables that we could possibly hit. Regards, Fede