[Haskell-cafe] Version constraints and cabal.config files

[Michael Snoyman]

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 <acowley at 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 <michael at 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 <acowley at gmail.com> wrote:
>
>>
>>
>>
>> On Mar 26, 2015, at 3:21 AM, Michael Snoyman <michael at snoyman.com> wrote:
>>
>>
>>
>> On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <acowley at gmail.com> wrote:
>>
>>>
>>>
>>>
>>> On Mar 25, 2015, at 11:03 AM, Michael Snoyman <michael at snoyman.com>
>>> wrote:
>>>
>>>
>>>
>>> On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <acowley at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mar 25, 2015, at 10:51 AM, Michael Snoyman <michael at snoyman.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <acowley at seas.upenn.edu>
>>>> wrote:
>>>>
>>>>> On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <michael at snoyman.com>
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> > On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <
>>>>> acowley at 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150326/93bf6efd/attachment.html>