Split off the BuildPlan code into its own package

[snoyberg]

By popular request. This issue is to figure out the functionality the code should have. For reference, this is referring to the code at:

https://github.com/fpco/stackage-server/blob/master/Handler/BuildPlan.hs

The results can be viewed online at, e.g.:

https://www.stackage.org/lts/build-plan?package=http-client&_accept=application/x-sh

[ttuegel]

There are two things I'd like to tweak about that script. First, it would be nice to be able to set an arbitrary mirror for the packages. Second, I would like to modify the output script so that the building phases are abstract. What I mean is, instead of invoking programs directly,

wget $url
tar xf $tarball
cd $prefix
runhaskell Setup.hs ...
...

the script would just invoke some shell functions

build_plan_fetch $url
build_plan_unpack $tarball
build_plan_build $prefix

that would be defined in a wrapper. The build plan script wouldn't be executable itself, rather we would have wrappers that source the build plan after defining those functions, i.e.

#!/bin/sh
build_plan_fetch() { ... }
build_plan_unpack() { ... }
build_plan_build() { ... }
# do some setup here
. build_plan.sh
# do some cleanup here

This way, we can write wrappers that do things like pre-fetch all the packages (but build nothing) or do lots of setup work, without needing to modify the script generator. This also lets us fall back from wget to curl, for example.

[snoyberg]

Point (1) makes perfect sense, completely agree.

On (2): I'm guessing in that approach, there'd be a config option as to whether the build_plan_XXX functions are generate by the script or not, correct? Another option seems to be to add configuration options to control what tool is used for fetching, unpacking, etc. Either approach works for me, the advantage of the config approach is that you'd always end up with a self-contained shell script.

[ttuegel]

I think configuration options to control which tools are used is orthogonal to what I intend by having those functions. Certainly, I appreciate the benefit of having standalone scripts, but for distributing Cabal, it would be more useful to call the generated script from our existing bootstrap script. The reason I say that is orthogonal is that the non-standalone script allows deferring the configuration decision (i.e. what tools to use) until runtime, instead of requiring configuration when the script is generated.

[snoyberg]

@ttuegel I've split off the code into the following repo:

https://github.com/fpco/stackage-build-plan

I believe it supports your requests correctly. Below is an example session. The code base should be easy to tweak if you'd like it to do something slightly different. Can you give it a shot and, if you're happy with it, I'll release to Hackage.

$ ./dist/build/stackage-build-plan/stackage-build-plan --mirror http://hackage.haskell.org/package/ --snapshot nightly --commands abstract --format shell cabal-install
#!/usr/bin/env bash
set -eux


rm -rf mtl-2.1.3.1 mtl-2.1.3.1.tar.gz
build_plan_fetch http://hackage.haskell.org/package/mtl-2.1.3.1.tar.gz
build_plan_unpack mtl-2.1.3.1.tar.gz
cd mtl-2.1.3.1
build_plan_build 
cd ..

rm -rf network-2.6.0.2 network-2.6.0.2.tar.gz
build_plan_fetch http://hackage.haskell.org/package/network-2.6.0.2.tar.gz
build_plan_unpack network-2.6.0.2.tar.gz
cd network-2.6.0.2
build_plan_build 
cd ..

rm -rf text-1.2.0.4 text-1.2.0.4.tar.gz
build_plan_fetch http://hackage.haskell.org/package/text-1.2.0.4.tar.gz
build_plan_unpack text-1.2.0.4.tar.gz
cd text-1.2.0.4
build_plan_build -integer-simple
cd ..

rm -rf parsec-3.1.9 parsec-3.1.9.tar.gz
build_plan_fetch http://hackage.haskell.org/package/parsec-3.1.9.tar.gz
build_plan_unpack parsec-3.1.9.tar.gz
cd parsec-3.1.9
build_plan_build 
cd ..

rm -rf network-uri-2.6.0.1 network-uri-2.6.0.1.tar.gz
build_plan_fetch http://hackage.haskell.org/package/network-uri-2.6.0.1.tar.gz
build_plan_unpack network-uri-2.6.0.1.tar.gz
cd network-uri-2.6.0.1
build_plan_build 
cd ..

rm -rf HTTP-4000.2.19 HTTP-4000.2.19.tar.gz
build_plan_fetch http://hackage.haskell.org/package/HTTP-4000.2.19.tar.gz
build_plan_unpack HTTP-4000.2.19.tar.gz
cd HTTP-4000.2.19
build_plan_build 
cd ..

rm -rf random-1.1 random-1.1.tar.gz
build_plan_fetch http://hackage.haskell.org/package/random-1.1.tar.gz
build_plan_unpack random-1.1.tar.gz
cd random-1.1
build_plan_build 
cd ..

rm -rf stm-2.4.4 stm-2.4.4.tar.gz
build_plan_fetch http://hackage.haskell.org/package/stm-2.4.4.tar.gz
build_plan_unpack stm-2.4.4.tar.gz
cd stm-2.4.4
build_plan_build 
cd ..

rm -rf zlib-0.5.4.2 zlib-0.5.4.2.tar.gz
build_plan_fetch http://hackage.haskell.org/package/zlib-0.5.4.2.tar.gz
build_plan_unpack zlib-0.5.4.2.tar.gz
cd zlib-0.5.4.2
build_plan_build 
cd ..

rm -rf cabal-install-1.18.0.8 cabal-install-1.18.0.8.tar.gz
build_plan_fetch http://hackage.haskell.org/package/cabal-install-1.18.0.8.tar.gz
build_plan_unpack cabal-install-1.18.0.8.tar.gz
cd cabal-install-1.18.0.8
build_plan_build 
cd ..

[snoyberg]

Also, you should have write access to that repo now (you'll have to accept the invitation to the fpco organization).

[snoyberg]

Actually, let's discuss future modifications in the stackage-build-plan repo itself, closing this issue.