Merge lp:~simonklb/charm-helpers/include-empty-config-options into lp:charm-helpers
Proposed by
Simon Kollberg
Status: | Merged |
---|---|
Merged at revision: | 652 |
Proposed branch: | lp:~simonklb/charm-helpers/include-empty-config-options |
Merge into: | lp:charm-helpers |
Diff against target: |
26 lines (+4/-1) 2 files modified
charmhelpers/core/hookenv.py (+2/-0) tests/core/test_hookenv.py (+2/-1) |
To merge this branch: | bzr merge lp:~simonklb/charm-helpers/include-empty-config-options |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Charles Butler (community) | Approve | ||
Casey Marshall (community) | Approve | ||
Cory Johns (community) | Approve | ||
Review via email: mp+309105@code.launchpad.net |
Description of the change
See the issue in the commit message which caused this.
It's possible that this could break some charms if they are expect the config not to include the options with empty defaults which now will exist as None. I'm open to a less intrusive change if necessary.
To post a comment you must log in.
I'm not certain of the impact this has on existing charms which you have called out, but I am +1 to the behavior change proposed here.
I expect the charm-helper config declaration properly translates the None type values to the python None. This should retain all the compatibility required to accept this change, as the inline code expects None's as well in these cases. Typically guarded like so:
if not config('foobar')
or
if config('foobar') is not None:
as two primary examples i've seen historically.
I'll reserve approval pending others perspective on the matter, but as a prelim i'm OK with this change.