Skip to content

[MIXLIB-CLI-63] Add deprecated_option support#65

Merged
tas50 merged 2 commits intomasterfrom
MIXLIB-CLI-63/deprecated-option-support
Jun 7, 2019
Merged

[MIXLIB-CLI-63] Add deprecated_option support#65
tas50 merged 2 commits intomasterfrom
MIXLIB-CLI-63/deprecated-option-support

Conversation

@marcparadise
Copy link
Copy Markdown
Member

@marcparadise marcparadise commented Jun 5, 2019

Description

This commit adds deprecated option support by exposing a
new ClassMethod, deprecated_option. It will generate a
corresponding deprecated option, and if that option is used it will
handle mapping of the old option to the new and issue a warning.

deprecated_option accepts a subset of the parameters that option accepts.

Most importantly, a deprecated option can't have a default value.
There's a practical reason for this and a philosophical one.

Practically, it makes it easy to track the situation where someone has
set use_separate_defaults to false. In that case, we currently
can't tell whether the user provided the flag, or it was set as a default.
This could have been addressed, but:

Philosophically it makes more sense to not have a default value on a
deprecated item. If it's deprecated, you want people to stop using it.
If it has a default, it's effectively forced in-use at all times.

See function docs for further accepted parameters.

To allow deprecated options without warnings, use parse_options as
parse_options(ARGV, show_deprecations: false). By default, warnings
will be shown.

This also moves some formatting code into its own class -
it was causing methods to get mixed in that client classes didn't
need; and I reached the point where I needed to access the formatting
functions across methods in both Mixlib::CLI and
Mixlib::CLI::ClassMethods. It made more sense to move them outside of
the mixed-in bits, since it wasn't a concern of the caller that would be
inheriting those methods.

Signed-off-by: Marc A. Paradise marc.paradise@gmail.com

Related Issue

Resolves #63

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

  • I have read the CONTRIBUTING document.
  • I have run the pre-merge tests locally and they pass.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • All commits have been signed-off for the Developer Certificate of Origin.

@marcparadise marcparadise force-pushed the MIXLIB-CLI-63/deprecated-option-support branch from 85036d0 to 145ba5f Compare June 6, 2019 16:50
This commit adds deprecated option support by exposing a
new ClassMethod, `deprecated_option`. It will generate a
corresponding deprecated option, and if that option is used it will
handle mapping of the old option to the new and issue a warning.

`deprecated_option` accepts a subset of the parameters that `option` accepts.

Most importantly, a deprecated option can't have a default value.
There's a practical reason for this and a philosophical one.

Practically, it makes it easy to track the situation where someone has
set `use_separate_defaults` to `false`.  In that case, we currently
can't tell whether the user provided the flag, or it was set as a default.
This could have been addressed, but:

Philosphically it makes more sense to not have a default value on a
deprecated item. If it's deprecated, you want people to stop using it.
If it has a default, it's effectively forced in-use at all times.

See function docs for further accepted parameters.

To allow deprecated options without warnings, use parse_options as
`parse_options(ARGV, show_deprecations: false)`. By default, warnings
will be shown.

This also moves some formatting code into its own class -
it was causing methods to get mixed in that client classes didn't
need; and I reached the point where I needed to access the formatting
functions across methods in both Mixlib::CLI and
Mixlib::CLI::ClassMethods. It made more sense to move them outside of
the mixed-in bits, since it wasn't a concern of the caller that would be
inheriting those methods.

Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
Comment thread lib/mixlib/cli.rb Outdated
Comment thread lib/mixlib/cli.rb Outdated
Comment thread lib/mixlib/cli.rb Outdated
Signed-off-by: Marc A. Paradise <marc.paradise@gmail.com>
@marcparadise marcparadise force-pushed the MIXLIB-CLI-63/deprecated-option-support branch from 5bfcff0 to 840b5a6 Compare June 6, 2019 19:31
@tas50 tas50 added the Expeditor: Bump Version Minor Used by github.minor_bump_labels to bump the Minor version number. label Jun 7, 2019
@tas50 tas50 merged commit 3f0149e into master Jun 7, 2019
@chef-ci chef-ci deleted the MIXLIB-CLI-63/deprecated-option-support branch June 7, 2019 02:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Expeditor: Bump Version Minor Used by github.minor_bump_labels to bump the Minor version number.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add deprecations support

3 participants