On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acow...@gmail.com> wrote:
> > > > On Mar 25, 2015, at 11:03 AM, Michael Snoyman <mich...@snoyman.com> wrote: > > > > On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acow...@gmail.com> wrote: > >> >> >> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <mich...@snoyman.com> >> wrote: >> >> >> >> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acow...@seas.upenn.edu> >> wrote: >> >>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <mich...@snoyman.com> >>> wrote: >>> > >>> > >>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <acow...@seas.upenn.edu >>> > >>> > wrote: >>> >> >>> >> The suggestion to use "cabal install --dependencies-only ..." instead >>> >> of "cabal freeze" in that issue is really nicely presented. "cabal >>> >> freeze" is close to the right thing, but it's just not as fully >>> >> featured as "cabal install" (e.g. taking flags). >>> >> >>> >> As for Stackage, I think it would be helpful to cache the full build >>> >> plans computed for each package in Stackage. This is most of the work >>> >> my Nix tooling currently does, so it would be a big time saver. >>> >> >>> >> >>> > >>> > By "full build plans," do you mean the dist/setup-config file, or >>> something >>> > else? That file would be problematic since it's Cabal-library-version >>> > specific IIRC. If you're looking for the full listing of deep >>> dependencies >>> > and versions, we can extract that from the .yaml file using the >>> technique I >>> > mentioned earlier. >>> > >>> > Michael >>> >>> Yes, I meant the full listing of deep dependencies. >>> >>> >>> >> I've put together a Gist with an executable that does what I described: >> >> https://gist.github.com/snoyberg/5b244331533fcb614523 >> >> You give it three arguments on the command line: >> >> * LTS version, e.g. 1.14 >> * Name of package being checked >> * true == only include dependencies of the library and executable, >> anything else == include test and benchmark dependencies as well >> >> If that's useful, I can package that up and put it on Hackage. >> >> Michael >> >> >> This is very helpfulness, thanks! There is a bootstrapping issue, though, >> which is, I imagine, why both Miëtek and I have been writing much more bash >> than we'd like. But perhaps this becomes part of a cabal-install-like >> bootstrap.sh script to get things going. >> >> Anthony >> > > Oh, that's actually a great idea. What if we had a program that: > > 1. takes a set of packages that needs to be installed, and an LTS version > 2. computes the dependency tree > 3. writes out a shell script (possibly batch program?) to wget, tar xf, > and runghc Setup.hs in the correct order to get all of those packages > installed > > As you can tell from the program I just threw together, stackage-types > supports this kind of thing pretty trivially. > > Michael > > > Yes, that's what the Nix tooling does. The extra bits are building up > package databases suitable for each build without copying files all over > the place. That has the extra benefit of being able to reuse builds when > the recipe is unchanged. It is definitely not hard, but getting the build > plans from stackage in a portable way would be valuable. > > Anthony > OK, I've updated the Gist so that it produces a shell script that will install all necessary packages. It also has a nicer optparse-applicative interface now. https://gist.github.com/snoyberg/5b244331533fcb614523 One thing I didn't do here is add support for custom GHC package databases. I assume you'll need that, but wasn't sure exactly how you're doing that in Nix. If this is useful for you, I'll start a stackage-bootstrap repo, clean up this code a bit, and we can continue improving it from there. Michael
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel