Support for embedding all assets

[peterhoeg]

lucky is very nifty for line of business applications that do not necessarily see a lot of concurrent traffic and therefore would benefit from being able to simply bundle up all the various assets inside the resulting binary to simplify deployment.

References:

• https://github.com/schovi/baked_file_system
• https://github.com/busyloop/rucksack

[matthewmcgarvey]

@peterhoeg this sounds like a great idea, but I'm not sure if it would be in Lucky or in a separate shard. I would love to know if there are any blockers in Lucky right now that keeps it from happening, though! Do you know of anything?

[peterhoeg]

but I'm not sure if it would be in Lucky or in a separate shard

Just to elaborate on this part. The main functionality to embed assets in the final binary should definitely leverage an existing solution such as https://github.com/wyhaines/datapack.cr (or the original baked_file_system shard), but having support for this in lucky would be straight up awesome.

[jwoertink]

I like the idea. I'd love to see this as a shard first so it could be tested before being brought in. I think the tricky part will be that we do compile-time asset detection by reading the mix-manifest to see what the paths are... The "virtual" path would probably need to be the same 🤔

[peterhoeg]

I would love to know if there are any blockers in Lucky right now that keeps it from happening, though!

I simply don't know. I *do* know that there is some talk about a general interface for shards to use to reference embedded resources (see crystal-lang/crystal#9374) which you could reasonably argue should be sorted out before lucky commits to an implementation.

[peterhoeg]

I like the idea. I'd love to see this as a shard first so it could be tested before being brought in.

From a risk management point of view I absolutely agree with where you're coming from. I'm not entirely sure though how well that would work as we presumably would need some changes to lucky itself in order to abstract out file access to an adapter. But those are just implementation details.... ;-) I admittedly have not looked at the actual lucky sources to be able to say anything remotely intelligent about how much effort this requires but I'd love to take a stab at it - should have some time in a months time.

I think the tricky part will be that we do compile-time asset detection by reading the mix-manifest to see what the paths are... The "virtual" path would probably need to be the same 🤔

Sure, but having a single canonical source of truth for where to read files from should make things more robust, so I'm putting this in the "good thing" category.