search

ConstantineK / sqlshell

Lightweight TSQL PowerShell Module
GNU General Public License v2.0
3 stars 1 forks source link

Global EnvConfig file for local defaults. #5

Open SirCaptainMitch opened 6 years ago

SirCaptainMitch commented 6 years ago

Need to design a local json config file that can handle the localconfigs.

Will need supporting functions:

  1. Get-GlobalConfig
  2. Set-GlobalConfig
  3. Load-GlobalConfig

This will handle defaults and should be used in a way that is OS agnostic. The functionality should not be dependent upon the local system whenever possible.

mshamann commented 6 years ago

Going to use Invoke-SqGlobalConfig to replace set/load functions, less functions that do basically the same thing.

SirCaptainMitch commented 6 years ago

One thing I thought about was that Set/save global config will be needed to overwrite session/file variables so that will need to be built.

Ideally the user never has to actually update the config file unless they want to create their own. In that light, something to handle outputting a default one might be cool but also well outside the scope of the project.

ConstantineK commented 6 years ago

That's a good point on what a default file looks like.

If there's a configuration item we have (or want to add) do you think it would make sense to maintain a data dictionary/hashtable/whatever which defines our supported attributes so that we can emit them in a default way?

I am thinking we would end up with the current functions as you designed, but maybe an additional file called defaults.json (or whatever) which listed out each of the properties and some documentation about what they do, and just gate any PRs which add new configuration options by saying they must append to this file.

We can toss it in internal if you want to avoid cluttering up the root of the project, but I think that it would also be useful as the project grows to have one point to look to for all our configuration we might create.

mshamann commented 6 years ago

I am thinking we would end up with the current functions as you designed, but maybe an additional file called defaults.json (or whatever) which listed out each of the properties and some documentation about what they do, and just gate any PRs which add new configuration options by saying they must append to this file.

I like this idea. Kinda what I was thinking for sure.