What happens with relative pathes?

[matthiasbeyer]

Hi.

I have a question about relative pathes in layered configuration. For example if I have the following structure:

/
/root.toml
/foo/foo.toml
/foo/bar/bar.toml
/foo/bar/somefile.txt
/baz/baz.toml
/baz/somefile.txt

And I layer my configuration objects via the nesting, so I get two configuration objects:

1. root.toml + foo.toml + bar.toml
2. root.toml + baz.toml

Where do I end up with a path = ./somefile.txt in baz.toml? The PathBuf deserialized does not point to the right file, does it?
And I cannot find it after deserializing the objects because

1. I don't know which file the setting came from, so I cannot search relative to that files directory
2. If I would search the tree, foo/bar/somefile.txt would be found first, which is obviously wrong

---

Is there a strategy to handle such cases? Is there a way to make config-rs handle relative pathes?
I think it is in the scope of this crate and would love to see such a feature, even contribute code for it.

[matthiasbeyer]

Hi @mehcode any thoughts on this?

[matthiasbeyer]

I'm still interested in this.

[matthiasbeyer]

Hi.

This gets more and more relevant for me. I'm thinking about implementing it myself for this library, if it is okay with you to include such a change. I have to talk to my employer first, though, whether I can implement this on company time.
Still: Would you merge such a feature?

[fpoli]

You could try contacting the other maintainers mentioned here: #149 (comment)

[matthiasbeyer]

Yeah, I'll do that.
I'll use the shotgun approach: @dawid-nowak @eisterman @ignatenkobrain @joelgallant @LukeMathWalker @szarykott @up9cloud @vmalloc

[matthiasbeyer]

So, as the crate does not necessarily know about PathBufs, we cannot handle them in the codebase of this crate. Though, I was able to solve my usecase via the newly introduced Config::set_once() function (if anyone is interested how, see this scope, or if that is too complicated shoot me an email 😄 ).

I'll close this now.