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

Support default in addition to defaults #88

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

slycoder
Copy link
Contributor

  • 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.

* 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.
Copy link
Contributor

@drewsonne drewsonne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand you correctly...

This PR would treat the defaults section as if it were a fully configure section in the config file and if there were no other sections in the file, and the user had not specified one, we would use the defaults section. Is that right?

def __init__(self, config_file=None):
super().__init__(default_section='defaults')

self['defaults'] = dict(save_password=False)
self[self.default_section] = self.DEFAULTS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good stuff.

# For backwards compatibility, we check if they have a default
# section instead of a defaults section and do a little switcheroo as
# needed.
if self.has_section('default') and not self.has_defaults:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might get a bit confusing.
I saw:

  • the default section as being the config which is used when no arguments are provided to the cli.
  • the defaults section as being an "abstract" config which will fill in the gaps in the other configs.

If we say defaults and default are the same, which config is picked when no cli args are set? I would like to be be able to set some sort of default config, as for the most time I would be setting the same option again and again on the cli (onelogin-aws-login -C my_config)


self.file = config_file

if self.file is not None:
self.load()

@property
def has_defaults(self) -> bool:
"""True if the defaults section has settings beyond our defaults"""
Copy link
Contributor

@drewsonne drewsonne Apr 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I... am confused...? what's the difference between the defaults section and the defaults?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can clarify the comment, but I just meant that if it's properly initialized, they should have something beyond save_password (i.e., "our defaults") which we inject into the defaults section.

Copy link
Contributor

@drewsonne drewsonne Apr 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"""True if the defaults section in the config file has key/values in addition to those defined in onelogin_aws_cli.ConfigurationFile.DEFAULTS"""

am I understanding that right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, that's much more eloquent (although it occurs to me I should make the check more accurate than it is now).

@codecov-io
Copy link

codecov-io commented Apr 19, 2018

Codecov Report

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

Impacted file tree graph

@@            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%) ⬆️

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
Copy link
Contributor

Looping in @mumoshu for their interest

@slycoder
Copy link
Contributor Author

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
Copy link
Contributor

drewsonne commented Apr 19, 2018

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 = john@mycompany.com
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
Copy link
Contributor Author

Agree on both counts =).

@drewsonne
Copy link
Contributor

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

drewsonne added a commit to drewsonne/onelogin-aws-cli that referenced this pull request Apr 19, 2018
@slycoder
Copy link
Contributor Author

Agree on everything.

@@ -68,7 +85,10 @@ def section(self, section_name: str):
:param section_name: Name of the section in the config file
:return:
"""
if not self.has_section(section_name):
if not section_name:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@drewsonne This is the check I was referring to in regards to default section handling

drewsonne added a commit to drewsonne/onelogin-aws-cli that referenced this pull request Apr 21, 2018
drewsonne added a commit to drewsonne/onelogin-aws-cli that referenced this pull request Apr 21, 2018
slycoder pushed a commit that referenced this pull request Apr 21, 2018
* The config value should always fall back to `default`

* Specify defaults section as discussed in #88

* Add more verbose error handling

* Don’t include empty values in overrides

* Moved defaults from cli into config file

* Fix flake8

* Fix test cases

* Handle defaults so they are not written to the config

* Updated test cases to handle config precedence

* Removed defaults check

* Make sure duration is an int
@slycoder slycoder changed the title Fix a number of bugs relating to config file defaults Support default in addition to defaults Apr 21, 2018
@slycoder
Copy link
Contributor Author

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


def initialise(self, config_name='defaults'):
"""
Prompt the user for configurations, and save them to the
onelogin-aws-cli config file
"""
print("Configure Onelogin and AWS\n\n")
if not config_name:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will never be falsey unless calling functions pass a None value in. If that's the case, the default value for the method param should probably just be config_name = None.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, this got leftover from the merge.

if self.has_section('default') and not self.has_defaults:
print("It looks like you're using a the deprecated 'default' "
"section.\nConsider renaming the section to 'defaults'.")
self.default_section = 'default'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In regards to whether this is still relevant, it depends on how we want to use default. I will write some bits in the config section of the README and we can regroup and see if it is needed. Sound ok?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure this was just in response to the reported issue; upon investigating I realized that until recently initialization was writing to a profile named 'default' so it seems like we should support it (or do a major version bump).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah right. Your call. At the very least, I'll write details for the configuration behaviour. If you do close it, we can always come back to this branch.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, thanks. I'll pull the default swizzling into a separate PR and we can discuss there.

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

Successfully merging this pull request may close these issues.

3 participants