And do you want the information on the core packages (e.g., base, template-haskell, containers) as well, or should they be left out?
On Thu, Mar 26, 2015 at 4:48 PM Anthony Cowley <acow...@gmail.com> wrote: > Yes, but a line-based format along the lines of: > > foo 1.2.3 > bar-baz 0.1.00 > > Would be easier to parse with the usual shell tools. > > Anthony > > On Mar 26, 2015, at 9:41 AM, Michael Snoyman <mich...@snoyman.com> wrote: > > Is the idea that you'd be able to make a query such as: > > GET > https://www.stackage.org/lts/1.14/build-plan?package=foo&package=bar&package=baz > > And get a result such as: > > [ {"name":"foo", "version":"1.2.3"} > , ... > ] > > ? > > On Thu, Mar 26, 2015 at 3:00 PM Anthony Cowley <acow...@gmail.com> wrote: > >> >> >> >> On Mar 26, 2015, at 3:21 AM, Michael Snoyman <mich...@snoyman.com> wrote: >> >> >> >> 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 >> >> >> Just having a URL from which to GET the build plan would be most useful. >> As you say, the actual package building happens after DB creation, and that >> requires knowing what to put in the DB. >> >> Anthony >> >
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
