[Hackage] #780: Simpler support for isolated/sandboxed builds

[Hackage]

#780: Simpler support for isolated/sandboxed builds
---------------------------------+------------------------------------------
  Reporter:  duncan              |        Owner:     
      Type:  enhancement         |       Status:  new
  Priority:  normal              |    Milestone:     
 Component:  cabal-install tool  |      Version:     
  Severity:  normal              |     Keywords:     
Difficulty:  unknown             |   Ghcversion:     
  Platform:                      |  
---------------------------------+------------------------------------------
Changes (by nathan.collins):

 * cc: nathan.collins@… (added)


Comment:

 I just attempted my first "sandboxed" build with Cabal, and failed, and I
 agree it could be much easier.  After about 2 hours I was still failing,
 and I came here to see if I had run into a bug.  But, trying the Capri
 package you mention above, I was able to figure out a sandboxed build in
 about 5 minutes!

 Here's where I gave up using `cabal` (some output elided here and in other
 examples):
 {{{
 $ ghc-pkg init ./cabal/packages
 $ prefix=`pwd`/cabal
 $ cd lib/replib-read-only
 $ cabal install --prefix $prefix --package-db=$prefix/packages
 $ cd ../../src
 $ cabal install --prefix $prefix --package-db=$prefix/packages
 ...
 Loading package RepLib-0.3.1 ... linking ... done.
 ...
 Registering trellys-core-0.0...
 cabal: trellys-core-0.0: dependency
 "RepLib-0.3.1-bd84a6d961076829097d3c4eb1eaee2c" doesn't exist (use --force
 to
 override)
 cabal: Error: some packages failed to install:
 trellys-core-0.0 failed during the building phase. The exception was:
 ExitFailure 1
 }}}
 I wonder if this is a bug, because the failure was after building and
 linking, and `ghc-pkg` knows about the package:
 {{{
 $ cd ..
 $ ghc-pkg list --package-conf cabal/packages/ -v
 using cache: cabal/packages/package.cache
 using cache:
 /home/collins/.ghc/i386-linux-6.12.1/package.conf.d/package.cache
 using cache: /var/lib/ghc-6.12.1/package.conf.d/package.cache
 cabal/packages/
    RepLib-0.3.1 (RepLib-0.3.1-bd84a6d961076829097d3c4eb1eaee2c)
 }}}

 Now, here's the successful `capri` version, for comparison:
 {{{
 $ capri bootstrap
 $ capri clone syb 'base-3*'
 $ capri import lib/replib-read-only
 $ capri import src
 }}}

 To be fair, the capri version had one hangup: in my first try I didn't
 have the
 {{{
 $ capri clone syb 'base-*'
 }}}
 line, and I got
 {{{
 ...
 Linking dist/build/trellys/trellys ...
 <command line>: unknown package: base-3.0.3.2
 cabal: Error: some packages failed to install:
 trellys-core-0.0 failed during the building phase. The exception was:
 ExitFailure 1
 }}}
 in the `capri import src` step.  But, a very similar error is covered in
 the second example in the Capri documentation (which in total is 12 pages
 in my browser, and onl y required skimming), so the solution was quickly
 found.

 Comparing the (failed) `cabal` version with the `capri` version, they're
 both simple. The difference is that it took me 2 hours to come up with the
 `cabal` version, versus 5 minutes to come up with the `capri` version.
 The reason for the time difference is that `capri`'s (short) documentation
 is all about doing what I wanted to do, whereas `cabal`'s (long)
 documentation has no section devoted to sandboxed installs.  So, assuming
 there is an easy way to do this with `cabal`, it would probably be enough
 to add a section to the documentation that explained the process for
 people that want to move from a (working, but not sandboxed) install
 process like
 {{{
 $ cd lib/replib-read-only
 $ cabal install
 $ cd ../../src
 $ cabal install
 }}}
 to a sandboxed one.

 P.S. the code I'm trying to build is a working copy of
 https://code.google.com/p/trellys/, in case someone is dying to debug my
 failed `cabal` sandboxed build :)

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/780#comment:1>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects