Support specifying module filenames relative to current file

[luxaritas]

Request

When specifying the filename parameter of module.file, relative filenames appear to currently be resolved relative to CWD. It would be great if it could be resolved relative to the current config or module file location.

Some possible options: 1) Change current behavior of relative paths 2) Add a constant that refers to the base directory of the current file 3) When loading a module, allow specifying a root directory that would apply recursively to any modules it includes unless it overrides it

Use case

I am currently building a set of custom modules to deploy across multiple services, and decided that a module.file would be the best approach for me. However (unless I'm missing something), when referencing other shared modules, I have to specify an absolute path, which can be less convenient and also requires passing down a root directory through all modules my shared modules could be located in different locations in different installations.

[rfratto]

I like this idea, and I think it would be very useful to remove the need for nested module.git instances, where the first module loader is a module.git, and every nested module uses module.file with some way of resolving relative paths.

Of the options you listed, 1 would be the most challenging to implement, since all components assume that paths are relative to the working directory. Changing that behavior across the board would be very challenging, and changing it just for module.file would be fairly confusing (IMO).

Add a constant that refers to the base directory of the current file

So far, this approach seems the easiest to implement, and potentially the most flexible. I like it.

When loading a module, allow specifying a root directory that would apply recursively to any modules it includes unless it overrides it

I'm not sure I'm following this suggestion exactly; what does it mean for a root directory to apply recursively to modules it includes?

[luxaritas]

Yeah my gut feeling was that option 1 would probably not be the way to go.

For option 3, imagine that we have the following situation: You have a root-config.river, which has a module.file reference to /opt/shared/a.river, which references /opt/shared/component1/b.river which references /opt/shared/component2/c.river. In my root-config, when referencing a.river, I could say "you belong to a package of modules all contained in /opt/shared". That way, b.river could reference c.river as "component2/c.river" rather than "../component2/c.river" (which winds up being more important if you wind up with nested paths more than a layer or two deep).

This would ideally complement the ability to relative import. It'd certainly be more complex to spec/implement, but figured I'd raise it as another possible option

[bentonam]

I think there are a couple things from this that are worth discussing.

Being able to set a root modules directory as a default would be beneficial, whether that is a command line flag or config. Tae the scenario where you're not using module.git but module.file in k8s, and you mount a ConfigMap/Secret containing multiple modules, or if one module references another, another, etc. The only way to reliably get that to work is to use a full path from the root /. Having to hard-code the full-path makes it more difficult when testing a config locally to a containerized environment. If there was a default modules directory setting, then paths would be relative from there would be useful.

I think @rfratto has purposed using constants.module_path

Would it be possible then to have module.git clones placed in that same directory? Placed in a folder that is the name of the module.git repo? It might be a separate issue, but that might help with some of the rate limiting issues that module.git can cause, given that each module.git is a separate clone. Maybe for module.git an argument of alias = "foo" can be set, that way other module.git instances using the same repo can reuse the same clone

[luxaritas]

I'd personally prefer the root module directory being provided via module config rather than global config, that way if you have multiple sets of modules (multiple git repos, multiple sets of folders from different sources, etc) they could all have their own unique roots, preventing the potential for conflict, etc.

[github-actions[bot]]

This issue has not had any activity in the past 30 days, so the needs-attention label has been added to it. If the opened issue is a bug, check to see if a newer release fixed your issue. If it is no longer relevant, please feel free to close this issue. The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your issue will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity. Thank you for your contributions!