if the included file is a relative path, then it should be located relative to the directory containing the including file. The current working directory of the process parsing a file must NOT be used when interpreting included paths.
But this does not hold true when I try to load my config files from outside of their directory.
For example, if I have a project that looks like this:
And app.conf has includes required("foo.conf"), main.go will fail to run hocon.ParseResource("configs/app.conf") because it can't resolve the path foo.conf from the myproject directory where main.go is running. But if I change the includes directive to be includes required("configs/foo.conf") then it works fine.
There are workarounds for this, but it breaks the standard definition of HOCON semantics and can create frustrations (for us, we want to run tests to verify config completeness from a different directory but then load configs from the same directory in shared environments where the application is running).
Problem
Per the HOCON docs:
But this does not hold true when I try to load my config files from outside of their directory. For example, if I have a project that looks like this:
And
app.conf
hasincludes required("foo.conf")
,main.go
will fail to runhocon.ParseResource("configs/app.conf")
because it can't resolve the pathfoo.conf
from themyproject
directory wheremain.go
is running. But if I change the includes directive to beincludes required("configs/foo.conf")
then it works fine.There are workarounds for this, but it breaks the standard definition of HOCON semantics and can create frustrations (for us, we want to run tests to verify config completeness from a different directory but then load configs from the same directory in shared environments where the application is running).
This bug can be exemplified in this test:
Proposed Solution
Resolve filepaths relative to the HOCON file with the
includes
directive, not the current working directory of the process.