On Wednesday, May 2, 2018 at 3:12:58 PM UTC-5, Manlio Perillo wrote: > Yes, but many developers may need a "debug" mode or more options available > to where to store the assets. > Why should a "standard" tool or API be restricted to where to store assets? >
I can kinda see where your going with having a debug mode. I've looked around too see what kinda tools are out there and found some in the awesome-go <https://github.com/avelino/awesome-go#resource-embedding> repo. Looking at some of these tools, packr looks like a tool that might work / be a good model for a standard tool: *In order to get static files into a Go binary, those files must firstbe converted to Go code. To do that, Packr, ships with a few tools to help build binaries. See below.* *During development, however, it is painful to have to keep running a tool to compile those files.* *Packr uses the following resolution rules when looking for a file:* 1. *Look for the file in-memory (inside a Go binary)* 2. *Look for the file on disk (during development)* From: https://github.com/gobuffalo/packr Would something like this be a good model? -- 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.
