Use a configuration.json instead of test_settings.py

[blaix]

See discussion here: #26 (comment)

[blaix]

@ekoval please keep the following things in mind:

• this is a public project. Any solution should not use anything internal to Yola.
• this is low priority. Work on it when you have nothing else to do
• as part of this issue: consider if this is even the right solution

[ekoval]

I faced this issue few times, and I can't say I like option with configuration.json.sample more thantest_settings.py. @beck, how will we generate and use that file, especially for public projects? Isn't configurator <service> qa --local Yola internal?

[zoidyzoidzoid]

yoconfigurator is public, but it is still quite heavily tied to private stuff, and expecting third parties working on this library to use it is a bit much, imho.

[stefanor]

how will we generate and use that file, especially for public projects?

By hand.

Yeah, yoconfigurator is public, but it isn't useful to anyone else, for generating configs, unless they do a bit of work. We can't expect anyone else to generate configs.

[beck]

I think a configuration.sample.json is fine

[blaix]

configuration.sample.json would let yola devs easily create env-specific configs, while still giving third-parties an easy way to set up their config by hand (as they have to do now with test_settings.py).

[ekoval]

I'm still not sure I understand this approach. Even if we have configuration.json.sample committed, it won't contain up-to-date configs, right? Because it is a dynamic file, which depends on deployconfigs and others. So developers will need to edit it anyway, which is much harder with JSON. Especially big JSON, because that config is quite big.
Another suspicious thing is that doing this way we expose Yola internals to public, because config contains many other things unrelated to the exposed public library. Or we're going to edit json.sample manually before we commit it into repository?

[blaix]

Yes. Edit manually before committing. And trim it down to the bare minimum
required to use the package. It won't matter that Yola devs generated
config will have a lot if extra stuff.

On Thursday, December 10, 2015, Eugene Koval [email protected]
wrote:

I'm still not sure I understand this approach. Even if we have
configuration.json.sample committed, it won't contain up-to-date configs,
right? Because it is a dynamic file, which depends on deployconfigs and
others. So developers will need to edit it anyway, which is much harder
with JSON. Especially big JSON, because that config is quite big.
Another suspicious thing is that doing this way we expose Yola internals
to public, because config contains many other things unrelated to the
exposed public library. Or we're going to edit json.sample manually before
we commit it into repository?

—
Reply to this email directly or view it on GitHub
#29 (comment).

[ekoval]

I can't say I like this solution. Very inconvenient for non-Yola developers.

[ekoval]

Even JSON with specific fields only has same structure as full JSON, it is not a plain config like this:

{url: <url>, username: <username>,...}

How about some mixed solution - if there is a configuration.json - use it. Otherwise try test_settings.py.
?

[blaix]

I imagined it would look something like this:

{
  "common": {
    "wlproxy": {
      "username": "...",
      "password": "...",
      "url": "...",
    }
}

That doesn't seem terribly inconvenient for third parties, but would make it very convenient for yola devs. Is something like that not possible? (admittedly, I haven't given it much thought) If so, what would the config have to look like?

[ekoval]

It is not terribly inconvenient, but looks quite unnatural. What is "common"? What is "wlproxy"? Why do I need it if I'm inside WLProxy, and don't know what "common" is?

[RayeN]

The problem is that the settings needed here aren't in common section of our configs, are they? (or do we plan to move them there). If so, generating proper configuration.json might not be simpler than just updating test_settings.py with proper data.

[blaix]

Those are all valid concerns. We should probably put this on hold until we have a better idea of how we're going to support per-partner auth anyway.

[stefanor]

If the interface is yoconfig, then the top level structure of our configs is irrelevant.