Customize the layering strategy

[grahamc]

From #4:

Currently, packages are split into layers based on how often they are referred to by other packages. But the reality for Rails is that most changes happen in gems and the source code, and not in the system dependencies. The source code and gems get stuck in that big final layer.

Ideally, we could customize layers the following can get their own layers:

• individual gems + deps
• compiled assets (output can be different without changes to Ruby code)
• Ruby code (which can change without modifying the asset output)

Here's a related promising PR: NixOS/nixpkgs#122608

[samueldr]

Noting here that while NixOS/nixpkgs#157670 seems relevant, and might help in many situations, it won't provide the desired control over layers. It only allows ensuring specific layers are made, dependencies of these layers may still be pushed in the "upper-most" (last) layer.

So e.g. having app.wrappedRuby in an explicit layer does not ensure all of its dependencies are present in previous layers, or at the layer itself.

What this means is that the "catch-all" layer with leftovers may still change in uncontrollable undesirable ways, and it may still be the biggest layer depending on layering elsewhere.