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

Bound environment variables get written to disk #1918

Open
3 tasks done
darrellwarde opened this issue Sep 11, 2024 · 2 comments
Open
3 tasks done

Bound environment variables get written to disk #1918

darrellwarde opened this issue Sep 11, 2024 · 2 comments
Labels
kind/bug Something isn't working

Comments

@darrellwarde
Copy link

Preflight Checklist

  • I have searched the issue tracker for an issue that matches the one I want to file, without success.
  • I am not looking for support or already pursued the available support channels without success.
  • I have checked the troubleshooting guide for my problem, without success.

Viper Version

1.19.0

Go Version

1.22.5

Config Source

Flags, Environment variables, Files

Format

JSON

Repl.it link

https://replit.com/@darrellwarde/Viper-example

Code reproducing the issue

No response

Expected Behavior

Upon writing config files, I would expect that only the following configuration values would be written to disk:

  • Default configuration values
  • Values already set in the configuration file
  • Values explicitly set using Viper.Set()

Actual Behavior

Configuration values from mapped environment variables get written to configuration file if they have values whilst writing config files. This is unexpected because you generally only expect environment variables to effect the behaviour of executions for which they are set, but because of this, they will be persisted to disk and still act as the configuration values when the variables are no longer set.

In the Repl.it, use the shell to set YEARS_SINCE_BORN during execution. Even though age is never explicitly set in the config, it gets written to the config file purely from the environment variable being set during execution.

Steps To Reproduce

No response

Additional Information

No response

@darrellwarde darrellwarde added the kind/bug Something isn't working label Sep 11, 2024
Copy link

👋 Thanks for reporting!

A maintainer will take a look at your issue shortly. 👀

In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues.

⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9

📣 If you've already given us your feedback, you can still help by spreading the news,
either by sharing the above link or telling people about this on Twitter:

https://twitter.com/sagikazarmark/status/1306904078967074816

Thank you! ❤️

@sagikazarmark
Copy link
Collaborator

Appreciate the detailed report @darrellwarde !

I don't think config writing has ever been a well-thought-out feature. I agree with your expectation, but others may use it as sort of a "dump" feature for any configuration they have which makes changing behavior like this extremely hard to change.

One thing we could do is make it configurable, defaulting to the current behavior. For example, allow passing a bit mask to Viper that tells it which config sources should be included in the written config.

Would you be open to creating a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants