It's certainly _possible_ to add such a feature, but I don't think it would be trivial. I'm not the primary maintainer of Stack any more, so I don't make decisions on what features would be added, but personally I'd lean towards handling this outside of Stack itself to avoid adding a lot of new file-transfer logic to it.
By the way, it's possible to achieve this same kind of binary caching by either performing builds in a Docker container, or even use Nix to deal with the binary caching and have Stack simply use the global GHC database provided by Nix (a coworker recently confirmed that this works as expected). On Wed, May 3, 2017 at 12:32 PM, Karl Ostmo <kos...@gmail.com> wrote: > Hi Michael, > > That does make sense for starting from scratch. > > The next major improvement would be sharing prebuilt binaries for > incremental additions to the contents in an existing STACK_ROOT. > > In our org, we rarely bump to newer LTS Haskell resolvers. However, we > more frequently add a new third-party package as a dependency to an > existing project. > This may result in 100+ developers paying a multiple-minute compilation > penalty for this new package on their own machines. > > There is an interesting Reddit thread comparing Nix and Stack for the > "CCACHE" use case: > https://www.reddit.com/r/haskell/comments/68tz2r/i_ > tried_haskell_for_5_years_and_heres_how_it_was/dh1uojc/?context=5 > > The consensus seems to be that the network-based binary caching I need is > only available through Nix. However, abandoning Stack for this feature, as > commenter "eacameron" suggests is necessary, is a difficult tradeoff: > https://www.reddit.com/r/haskell/comments/68tz2r/i_ > tried_haskell_for_5_years_and_heres_how_it_was/dh1ed3g/ > > How feasible would it be to integrate network-based binary caching > capability into Stack? > Would you accept pull requests for it? > > Karl > > > On Wednesday, April 26, 2017 at 10:10:28 PM UTC-7, Michael Snoyman wrote: >> >> On mobile, so just a short reply: you could try setting the STACK_ROOT >> environment variable to the same absolute path on all systems and copy that >> directory around. >> >> On Wed, Apr 26, 2017, 5:42 PM Karl Ostmo <kos...@gmail.com> wrote: >> >>> I and the other members of my project are all using using the same LTS >>> Haskell 5.9 with version 1.3.2 of Stack on identical Linux workstations. >>> >>> If I introduce a new dependency on a third-party library to the project, >>> I would like to upload my prebuilt binary artifact of that dependency to >>> some shared cache so that others do not also have to pay the compilation >>> penalty. >>> >>> For two developers, Alice and Bob, say that Alice has compiled the >>> project successfully, and Bob needs to set up his environment to do the >>> same. >>> >>> For one, even on the same machine, it does not yet seem possible to >>> simply copy the entire "/home/alice/.stack" directory to "/home/bob/.stack" >>> to bootstrap Bob's environment. >>> It seems that the path to the "stack root" directory itself is >>> hard-coded in many datafiles that live inside the stack root. >>> >>> Failing that, after Bob has already bootstrapped his stack root, perhaps >>> when Alice adds a new package dependency, it would be possible to copy some >>> subset of the content in "/home/alice/.stack" to Bob's stack root to avoid >>> compiling that single new dependency. >>> >>> The "~/.stack/precompiled" directory looks like a likely candidate for >>> artifacts to copy. However, there appears to be some opaque registration >>> process (seemingly involving "~/.stack/snapshots/x86_64-lin >>> ux/lts-5.9/7.10.3/pkgdb/package.cache") that must take place before the >>> copied binaries can actually be used. >>> >>> Has anyone else been down this road of binary sharing? >>> >>> Thanks, >>> Karl >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "haskell-stack" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to haskell-stac...@googlegroups.com. >>> To post to this group, send email to haskel...@googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/haskell-stack/77a374c1-4e78-4f5f-aa36-965e8d7758e4%40goo >>> glegroups.com >>> <https://groups.google.com/d/msgid/haskell-stack/77a374c1-4e78-4f5f-aa36-965e8d7758e4%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "haskell-stack" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to haskell-stack+unsubscr...@googlegroups.com. > To post to this group, send email to haskell-stack@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/haskell-stack/64cea8c0-119f-437e-a754-6ac3d5636294% > 40googlegroups.com > <https://groups.google.com/d/msgid/haskell-stack/64cea8c0-119f-437e-a754-6ac3d5636294%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "haskell-stack" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stack+unsubscr...@googlegroups.com. To post to this group, send email to haskell-stack@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/CAKA2Jg%2BbY%3DqoQ3w_t-HAZua5He_dRyiKSg_FWVyCqJdCxCRkEA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
