Shall we avoid editing DBCon.py?

[xlight05]

Context

When we are configuring the database, we are encouraging people to use hard-coded values in DBCon.py.

I don't really mind hard coding values in a config file for testing purposes however it really is a bad practice to edit the code. I've done this myself and I accidentally staged DBCon.py couple of times.

I think the solution is already implemented. In the default code, we are getting values from the environment variables. I believe its correct, I think we should encourage users to use the env variables and remove editing DBCon.py in the README and Wiki pages.

Maybe we can provide a template .env file for usability. What do you think? If you agree, I can start working on this.

[hv7214]

@kmehant what you say? I think it's better to make a template .env file rather making env variables/directly populating credentials.. It becomes really easy for a developer to configure a database, and hence prevent accidental staging of DBCon.py file.

[JaDogg]

Can we create an inheritable config system. We have config.json and user.config.json. We will commit config.json and not commit user config. We can put default values there in config.json.

When loading the config we load both and merge in a way user.config.json overrides config.json data.

If we do .ini or .yml We can also have comments 😀

--

Then we create a config class to handle all this. Have every other class create and use configs or use a method like cfg["config"] (using __getitem__)

[hv7214]

@JaDogg it seems a great idea to go, though i have a lil'bit different approach. We can have a config.example.json, which should be treated as a template file. User has to duplicate this file as config.json (leading to two files: config.json and config.example.json). So data will be loaded directly from config.json file. No merging stuff. And config.json will be added to .gitignore, so no headache of staging.

[JaDogg]

We can simply use ChainMap for merging and some custom code to handle nested merging. We can use .yml and include comments and examples in the same config. Example config is OK as well for Bassa.

Currently I'm not sure if it is possible to just run Docker to get stuff working. If I remember correctly we need to set some environment variables. @kmehant knows I think

[hv7214]

as much i know env variables are used for database config.

[kmehant]

We can simply use ChainMap for merging and some custom code to handle nested merging. We can use .yml and include comments and examples in the same config. Example config is OK as well for Bassa.

Currently I'm not sure if it is possible to just run Docker to get stuff working. If I remember correctly we need to set some environment variables. @kmehant knows I think

Yup no need to set environment variables in the case of container setup as we have mocked all of them using docker-compose tool

[hv7214]

@JaDogg so should i just go with your idea or mine one.

[carpecodeum]

@hv7214 as far as i know using .env can create in problems in the travis builds too so a solution without the use of .env files seems more appropriate.Also I think your use of sample config.json is fine. 👍

[JaDogg]

Either way is fine as long as we have good enough defaults for testing/dev somewhere. :)