Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write support #114

Open
dhardy opened this issue Oct 13, 2023 · 1 comment
Open

Write support #114

dhardy opened this issue Oct 13, 2023 · 1 comment

Comments

@dhardy
Copy link

dhardy commented Oct 13, 2023

For a "merged config object" like the old config-rs, I would assume that the first step of writing config would be to diff the merged object with another using default values. The layered approach of config-rs-ng provides a better option, namely that an appropriate layer can be selected when attempting to save a value. Potentially the appropriate layer could be chosen explicitly or could be chosen based on having write support.

Only one (or a small number) of types of layer need support writing. As mentioned in the blog, it would be nice if the writer is configuration-preserving, but this is not technically required.

I think a minimal-viable-candidate would be for layers to optionally support setting values (internally) and writing (write-to-source), along with a File layer which uses serialisation for writing.

A couple of complications:

  • If a config-stack supports an optional user-configuration-file which is not present on the system, but this is the only source supporting writing, then presumably this layer needs to be created even though the file does not exist. This may also require the writer to create the target directory when writing.
  • In the simplest case, all written values would go to the first layer in the stack supporting writing. This might not always be desired. I guess the easiest answer here is to allow optionally specifying which layer to use.
@matthiasbeyer
Copy link
Owner

So in general I would like this to be possible, as it is a feature that has some demand already. But I fear that it is either highly complex to get right (implementation wise) or really hard to be used right.
I wouldn't mind any experiments (as in PRs) to tackle this problem, though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants