Finding boxes in the sub-packages about go.rice

[vkryukov]

I now see that it is related to #47 and having a Ricefile. Feel free to close this one if you think it will be captured by #47.

[GeertJohan]

Have you tried adding multiple boxes by using the --import-path or -i flag (multiple times) to search through other packages.

[GeertJohan]

And yes, Ricefile will be a better solution for this. If you have any thoughts on it please respond in that topic, I could really use feedback and brainstorm material.

[vkryukov]

No, I haven't tried using --import-path. I actually reflected about my needs some more, and switched to esc - a much simpler solution, this blog post by author explains the reasoning behind yet another go asset embeder.

Here is what convinced me: we do have a go generate step anyway, why don't keep all the configuration in the go:generate line? I can see how Ricefile could be useful for more complex projects with multiple different boxes etc., but my case is really simple - static assets for a web-server - and one line

//go:generate esc -o assets.go -prefix=assets assets/

with

assetServer := http.StripPrefix(("/_static/"), http.FileServer(FS(false)))
http.Handle("/_static/", maxAgeHandler(3600, assetServer))

in main solves all my problems. For an occasional need for a specific resource I've proposed adding FS(Must)?(String|Byte) which was accepted by Matt.

This is not to convince you to drop developing go.rice and switch to esc, not at all :) - just sharing my thoughts.

[vkryukov]

BTW, since esc compresses all the assets, it dramatically reduces the compilation time. I have a $10 box at DO with 1 cpu and 1GB of RAM, and golang simply failed to compile my project, which included jquery and bootstrap, among other libraries, until I significantly increased the swap space.

esc approach is to gunzip assets in memory on first use, so the performance impact is almost neglectable, esp. for long running processes.

[GeertJohan]

@victorkryukov Good to hear you have a solution and thanks for your view on these things. I agree that rice aims on more complex cases (multiple directories, files, options). That is also where I want to go with rice 2.0 and the Ricefile. Compressing the data is really interesting, I hadn't thought about that yet.

Since --import-path would probably solve your problem, I will close this issue.

[vkryukov]

@GeertJohan absolutely. Good luck with Rice 2.0 - I'll definitely keep an eye on the development.