<div dir="ltr">If anybody else is interested.<div>For now, I settled with a Stack based solution.</div><div><br></div><div>`STACK_ROOT=<some-temp-folder> stack build --dry-run --prefetch`</div><div><br></div><div>works like a charm. What I didn't tackle yet is having multiple ghc installations in that folder. Somehow I will find a solution for that as well.</div><div><br></div><div>For now I live with the fact that</div><div><br></div><div>`STACK_ROOT=<extracted-archive-from-prior-step> stack build --install-ghc`</div><div><br></div><div>will connect to the internet to download ghc.</div><div><br></div><div>Thanks for all the responses. I'll send an update when the ghc thing is solved as well.</div><div><br></div><div>Best</div><div>Jan<br><br><div class="gmail_quote"><div dir="ltr">Herbert Valerio Riedel <<a href="mailto:hvriedel@gmail.com">hvriedel@gmail.com</a>> schrieb am Do., 24. Nov. 2016 um 22:48 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="gmail_msg">
<br class="gmail_msg">
On 2016-11-24 at 07:57:57 +0100, Jan von Löwenstein wrote:<br class="gmail_msg">
> Consider the following use case:<br class="gmail_msg">
> I have to ship a Haskell application as source, bundled with its<br class="gmail_msg">
> dependencies and a script that can produce the binary on a machine without<br class="gmail_msg">
> internet connectivity.<br class="gmail_msg">
<br class="gmail_msg">
This situation is not that uncommon; one example is when you have<br class="gmail_msg">
build-bots which a more or less cut off from the internet (such as<br class="gmail_msg">
Ubuntu's launchpad buildfarm)<br class="gmail_msg">
<br class="gmail_msg">
> Is that possible with Stack or Cabal?<br class="gmail_msg">
> Any pointers would be much appreciated.<br class="gmail_msg">
<br class="gmail_msg">
> Ideally I would like to build each dependency package individually. That<br class="gmail_msg">
> way I could cache results per Haskell package and don't need to rebuild<br class="gmail_msg">
> dependencies until they actually change.<br class="gmail_msg">
<br class="gmail_msg">
This sounds like something I'd use cabal's filesystem-local repository<br class="gmail_msg">
feature[1] for, and it should be possible to specify such local<br class="gmail_msg">
repositories in your `cabal.config` or `cabal.project`[2] files to<br class="gmail_msg">
produce a self-contained source distribution.<br class="gmail_msg">
<br class="gmail_msg">
If you're interested in pursuing this approach or have any questions<br class="gmail_msg">
about it, let me know!<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
 [1]: <a href="http://cabal.readthedocs.io/en/latest/installing-packages.html#repository-specification" rel="noreferrer" class="gmail_msg" target="_blank">http://cabal.readthedocs.io/en/latest/installing-packages.html#repository-specification</a><br class="gmail_msg">
 [2]: <a href="http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html" rel="noreferrer" class="gmail_msg" target="_blank">http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html</a><br class="gmail_msg">
<br class="gmail_msg">
Cheers<br class="gmail_msg">
</blockquote></div></div></div>