Finding boxes in the sub-packages

[vkryukov]

I know it says so in the TODO section in the README, but go.rice needs to support finding boxes in packages.

I have an local webserver app that is using rice to store resources, but it doesn't work for the packages I import, even when these packages use rice embed-go strategy to store their assets. That's really limiting my ability to use rice, and I guess I'm not the only one with this problem.

I'm creating this issue to track the progress. I'm would like to work on this and would appreciate any pointers on where should I start.

[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.