Hi Seb! :) On Thursday, October 19, 2017 at 9:00:46 PM UTC+2, Sebastien Binet wrote: > > On Thu, Oct 19, 2017 at 8:51 PM, Alex Buchanan <buchan...@gmail.com > <javascript:>> wrote: > >> But, maybe a better solution is to faithfully record the current git (or >> other VCS) details you'd need to find the code which resulted in the >> binary? That way you have access to the source in its natural state. >> > > yes. > using go-bindata is a nice, quick'n'dirty solution for the problem at > hand, but I fear it's just duplication of work somehow. > why not just using "dep" that captures the state of the code (ie: git sha) > *and* its dependencies. > > this sounds more reliable. at least to me. > and it encourages people to put their code into a repository which, for > reproducibility of scientific results, is step-0. >
Absolutely, and this is what we do for our own use. What I'm thinking about is how the ability to compile a workflow to a binary will make it easy to ship "ready made" workflows for less tech-savvy users, who might not be comfortable using git and the go tools, or might do unwarranted, undocumented changes if we'd just give them the Go source and the Go tools. Best // Samuel -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
