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

Create some common configuration management lib #52

Open
ghost opened this issue Mar 2, 2016 · 2 comments
Open

Create some common configuration management lib #52

ghost opened this issue Mar 2, 2016 · 2 comments

Comments

@ghost
Copy link

ghost commented Mar 2, 2016

Currently, for common parts of the configuration in our different projects, we're rewriting those in each project.

The result is that some common configuration bits appear completely differently in the way the configuration of each project is structured. This was actually confusing for some people trying to look at the different configuration files.

Such common configuration should have the same format, and thus be written only once. As such; I'm suggesting that we write a small config management lib, that at least includes the logging concern, and that generates a werelogs configuration object from the given configuration section. It would help harmonize configuration formats, and could easily bring more flexibility to our logging configuration.

@ghost ghost added the enhancement label Mar 2, 2016
@adrienverge
Copy link
Contributor

Agreed.

I proposed this (a common config lib) last year, but it was rejected because 1) it would add another dep 2) we wanted configuration to be "hidden" to customers, i.e. not accessible through a file. Please make sure those are not considered problems now.

@ghost
Copy link
Author

ghost commented Mar 3, 2016

  1. we've already come back on that dependency decision since we're now going to use arsenal for common error management.
  2. even if we do not want to explicitly show the configurations, some will get to it, and it's better to be consistent throughout the project in any case, and reduce the ducplication of the code for the configuration management

As such, I do not think it is a problem anymore :)

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

No branches or pull requests

1 participant