
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br></div><div><br>On Mar 26, 2015, at 3:21 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><br><div class="gmail_quote">On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley <<a href="mailto:acowley@gmail.com">acowley@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br><br></div><div><br>On Mar 25, 2015, at 11:03 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><br><div class="gmail_quote">On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley <<a href="mailto:acowley@gmail.com" target="_blank">acowley@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div><br>On Mar 25, 2015, at 10:51 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><br><div class="gmail_quote">On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley <<a href="mailto:acowley@seas.upenn.edu" target="_blank">acowley@seas.upenn.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br>

><br>

><br>

> On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley <<a href="mailto:acowley@seas.upenn.edu" target="_blank">acowley@seas.upenn.edu</a>><br>

> wrote:<br>

>><br>

>> The suggestion to use "cabal install --dependencies-only ..." instead<br>

>> of "cabal freeze" in that issue is really nicely presented. "cabal<br>

>> freeze" is close to the right thing, but it's just not as fully<br>

>> featured as "cabal install" (e.g. taking flags).<br>

>><br>

>> As for Stackage, I think it would be helpful to cache the full build<br>

>> plans computed for each package in Stackage. This is most of the work<br>

>> my Nix tooling currently does, so it would be a big time saver.<br>

>><br>

>><br>

><br>

> By "full build plans," do you mean the dist/setup-config file, or something<br>

> else? That file would be problematic since it's Cabal-library-version<br>

> specific IIRC. If you're looking for the full listing of deep dependencies<br>

> and versions, we can extract that from the .yaml file using the technique I<br>

> mentioned earlier.<br>

><br>

> Michael<br>

<br>

Yes, I meant the full listing of deep dependencies.<br>

<br><br></blockquote><div><br></div><div>I've put together a Gist with an executable that does what I described:</div><div><br></div><div><a href="https://gist.github.com/snoyberg/5b244331533fcb614523" target="_blank">https://gist.github.com/snoyberg/5b244331533fcb614523</a></div><div><br></div><div>You give it three arguments on the command line:</div><div><br></div><div>* LTS version, e.g. 1.14</div><div>* Name of package being checked</div><div>* true == only include dependencies of the library and executable, anything else == include test and benchmark dependencies as well</div><div><br></div><div>If that's useful, I can package that up and put it on Hackage.</div><div><br></div><div>Michael </div></div></div>

</div></blockquote><br></div><div dir="auto"><div>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.</div></div><div dir="auto"><div><br></div><div>Anthony</div></div></blockquote><div><br></div><div>Oh, that's actually a great idea. What if we had a program that:</div><div><br></div><div>1. takes a set of packages that needs to be installed, and an LTS version</div><div>2. computes the dependency tree</div><div>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</div><div><br></div><div>As you can tell from the program I just threw together, stackage-types supports this kind of thing pretty trivially.</div><div><br></div><div>Michael </div></div></div>

</div></blockquote><br></div><div dir="auto"><div>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.</div></div><div dir="auto"><div><br></div><div>Anthony</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div><a href="https://gist.github.com/snoyberg/5b244331533fcb614523">https://gist.github.com/snoyberg/5b244331533fcb614523</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Michael</div></div></div>

</div></blockquote><br><div>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.</div><div><br></div><div>Anthony</div></body></html>