Port Bcfg2 command line option parsing to optparse

[https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU]

Now that minimum Python version for Bcfg2 is above 2.3, where optparse was introduced, it is save to port current option parsing mechanism there.

This will help to create consistent multi-level user interface that is easier to extend, debug, and maintain as well without breaking existing functionality.

The above is achieved by decoupling option parsing from configuration load.

[solj]

The optparse module is already deprecated. Looks like argparse should be used, however, it is only available in 2.7, so we will probably stick with the current configuration parsing for the time being.

[https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU]

Switching from optparse to argparse is no-op when we are ready to abandon Python 2.6. There is no reason to abandon benefits of switching to optparse just because there is a more advanced version of it available in future Python versions which Bcfg2 doesn't support yet.

[https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc]

What would be gained by what would be a substantial rewrite? The option parsing stuff is already very easy to extend and maintain thanks to the Bcfg2.Options abstraction layer. And it's important that option parsing remain coupled to loading the configuration file, since there are lots of options that can be supplied in either place. The Bcfg2.Options layer handles this.

Unless someone wants to contribute a patch, I don't see that we gain anything from this, and there is other code that needs our attention more.

[https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU]

Replying to https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc:

What would be gained by what would be a substantial rewrite?

It's not substantial. When I figure out how to sync my branch with latest trunk/ and upload it to Git, I'll show you the prototype.

The option parsing stuff is already very easy to extend and maintain thanks to the Bcfg2.Options abstraction layer.

Recent problems with bcfg2-admin init and issue #1033 proves otherwise. =)

And it's important that option parsing remain coupled to loading the configuration file, since there are lots of options that can be supplied in either place. The Bcfg2.Options layer handles this.

Don't get 'de-coupling' wrong. Instead of mixing everything related to configuration into one big chunk of spaghetti code, you create a layered salad. But that's still a complete dish. The maintainable solution for option parsing stuff will look like this:

1. Parse command line options
2. Process command line options not related to configuration
3. Load default configuration (options are still
4. Update configuration with user level settings from config file
5. Update configuration from options dict (merge configuration related options)

Unless someone wants to contribute a patch, I don't see that we gain anything from this

A sufficient reason to leave this ticket open.

[solj]

Moving to 1.3 since this won't be done in time for 1.2.

[https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc]

Since optparse is officially deprecated in Python 3, it would take a lot of legwork to maintain an option parser that was compatible with both optparse and argparse. getopt will remain compatible with both Python 2 and 3 for the forseeable future, so not only would moving to optparse/argparse not gain us anything, it would actually cause more work and more abstraction issues with Py3k.

Given that the patch promised 10 months ago has not materialized -- and given that, unless that patch offered full compat with Py3k in a sane and reasonable way, I would not want to accept it -- I'm closing this as wontfix. We can revisit this issue when Bcfg2 requires Python 2.7, which will likely be 2021 at the soonest. (I don't see any value in keeping a tracking ticket open for 9 years.)

[Richardheef]

If perspex in a presynaptic hand looked similar to her or was holding wreck she liked, she would walk not widely to and attach herself to who or what had caught her regulation. ​https://my.swu.edu/ICS/icsfs/tabfen23.html?target=55813c58-b2dc-4a77-aad4-a1f5f1c86a98 A side soil can be used to avoid topic, with either time, actuality, or ephedrine being original, one of the humans being third, and the large being extant.