Support default in addition to defaults

[slycoder]

• initialize should write to the default_section.
• handle the case where initialize is called without a section.
• handle legacy config files with default instead of defaults.
• handle config files without a profile section aside from the defaults.

[codecov-io]

Codecov Report

Merging #88 into master will increase coverage by 0.25%. The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #88      +/-   ##
==========================================
+ Coverage   74.02%   74.27%   +0.25%     
==========================================
  Files           6        6              
  Lines         308      311       +3     
==========================================
+ Hits          228      231       +3     
  Misses         80       80

Impacted Files	Coverage Δ
onelogin_aws_cli/configuration.py	93.75% <100%> (+0.3%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 3258bc3...3a3d7f2. Read the comment docs.

[drewsonne]

Looping in @mumoshu for their interest

[slycoder]

I guess at a top-level we need to decide how defaults + profiles should work. It just seemed to me odd that the config file wouldn't work with only a defaults section.

In allowing that, this PR changed a bunch of places where it assumed the existence of a non-"defaults" profile, while at the same time supporting a "default"-only legacy config file.

@drewsonne I think your reasoning makes sense for how you'd want to deploy the configs in a lot of environments; I'm just uncertain as to whether that should be "enforced".

[drewsonne]

I'm with you so far, and not interested in enforcing any particular workflow, but I am selfishly hoping my use case will work. :-)

Can I put some points out and we'll see where we agree/disagree?

1. There is a defaults (with an s) section, which is used as both a configuration profile unto itself and an "abstract" configuration profile which other configuration profiles will automatically pull their values from if they are missing any.

2. If 1. is implemented, there is no need for a "special" default (without an s) section, as its functionality would be covered by the defaults (with an s) section.

3. The configuration profile which should be chosen if the user does not provide one is defaults.

4. As an example,

[defaults]
base_uri = https://api.us.onelogin.com/
subdomain = mycompany
username = [email protected]
save_password = yes
client_id = f99ee51f00400649280db1028ffa3ca9b21b680f2189b238d342cc8158c401c7
client_secret = a85234b6db01a29a493e2422d7930dffe6f4d3a826270a18838574f6b8ef7c3e
aws_app_id = 555027 # r&d

[testing]
aws_app_id = 555029 # testing

[live]
aws_app_id = 555070 # live

If I wanted to log into my "r&d" account, I will call:

$ onelogin-aws-login

or

$ onelogin-aws-login -C defaults

testing account:

$ onlogin-aws-login -C testing

staging account:

$ onelogin-aws-login -C staging

Is that right/reasonable?

[slycoder]

Agree on both counts =).

[drewsonne]

I made an edit, and shan't edit more. All 4 points are ok?

[slycoder]

Agree on everything.

[slycoder]

Alright, this PR now up-to-date. @drewsonne , do you think this PR is still worthwhile.