Feature Request: namespaces for library flake support #93
Description
@eclairevoyant This is a bit of what was said to @NotAShelf in DMs. I recently encountered this issue. Thought you would be interested in proactively finding a solution as well.
If library style module flakes are inputs by two other flakes which are both consumed by the same flake (say like a host system consuming two other flakes which use hjem or wrappers for implementation), you'll encounter a diamond problem
The module system usually resolves duplicate importing and resolves module paths to the same module. However, if both flakes' inputs are different versions or even slightly alterred, the modules don't resolve and the module system throws an error on duplicate named options
You could resolve this by making the flake inputs follow the same input as each other. But if one is through npins or maybe deeply nested enough that you cannot override input, you cannot trivially make them follow the same implementation. Also, say if there's a breaking issue in said library module flake, you wouldn't be able to make them follow to the same input anyways
There's another case where this occurs as well. If you have a function generator of a module or eval time created module, despite the paths resolving to the same generated module, the module system is incapable of completing telling if they're the same (as it should because different arguments of the function would create different modules but it is hard to still tell if arguments passed were the same
In either of the above cases, the module options need to be namespaced to create different option scopes so they do not conflict in the module system. My idea is something simple like:
"${namespace}-<flake-name>"for namespaces options. But for toplevel usage by the user where it is treated less like a dependency and more like a tool, no namespacing is required and the simple straightforward usage ofhjem.orwrappers.options is pretty fine to use