Allow dynamically reading either from the file system or the embedded binary, with configurable runtime order

[alcroito]

Hi,

Thanks for the great crate!

I'd like to request a new feature where files are always embedded regardless of build type, but queried files can be read either from the file system or from the embedded blob, configurable at run time, with fallback to the other access kind.

For example I'd configure filesystem access to have precedence.
In that case:

1. if a.txt exists in the FS, it would be returned
2. if a.txt does not exist in FS, the implementation would try to look it up in the embedded blob and return it from there
3. If a.txt does not exist either in the FS, nor is it embedded, then None would be returned.

This is similar to what golang's go.rice package offers.
https://github.com/GeertJohan/go.rice

It allows configuring the order of precedence.
https://pkg.go.dev/github.com/GeertJohan/go.rice#Config

I realize this is likely a bigger design change compared to what the crate currently offers, but i think it would be a useful addition.
If adding fallbacks is too much work, a simpler change would a new feature to always generate both the fs and embedded code paths, and introducing a new api that would take as a param which code path to use at runtime.
Then application code can handle fallbacks and the query order.

[pyrossh]

Hi @alcroito

Thank you on behalf of the amazing contributors and nice idea.

This seems to me like a counter design of what rust-embed is trying to fix. As the reason this library was created before include_dir! was implemented was to embed assets in release only.

Another reason was certain apps could have a large set of assets in the millions (I'm looking at you node_modules) which would take the compiler a large amount of time in the dev/debug build phases if include_dir! marco or the like was used. So during these phases we would want to load the assets from the fs. I do have an app with an assets folder of 2GB+ and 100,000+ files. rustc takes min 20 mins to compile the binary on my system (golang takes 5 mins).

But yes it would make it simpler in cases where the file count/size is small or irrelevant and wouldn't affect dev compile times and our dev/release builds would be identical in functionality. Even the go embed implementation embeds the dirs both during dev/release (which has its own set of issues again).

I think we can start this our as a new feature/api in another branch and test it out and maybe get some feedback from the users of this library about how they would feel about this api. Would you be interested in a PR for this?