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
