|
The main reason for the current implementation (a file layout) is the puppet runtime relies on the layout on disk and file paths to a very high degree. While there could be an API for an environment provider, without quite extensive changes, that environment provider would have to lay down the information on disk and essentially construct a module path that consists of roots of all modules.
I think it is well worth exploring as the knowledge about mapping names to paths is both complicated and implemented in multiple places (autoloader, 4.x loaders, module tooling, puppet server). There is one complication with an API approach as it requires that the environment providers are available in Ruby (later C++) as well as in the JVM (in an efficient way). Now, this is not required since the API is the paths in the file system (plus modulepath). (Imagine an environment provider that is served from in-memory, or from a DB.
If the intent here is to provide "on demand file system layout for an env" then that may be completely doable without extensive changes. I don't see how such an API would have an impact on caching logic or env isolation - it would basically just automate the copying/linking into the right file system location on demand instead of a-priori. There may be a small performance penalty as the module path would grow in size.
|
