Modify

Ticket #1060 (closed defect: wontfix)

Opened 10 years ago

Last modified 7 years ago

Port Bcfg2 command line option parsing to optparse

Reported by: https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU Owned by: desai
Priority: major Milestone:
Component: bcfg2-client Version:
Keywords: Cc:

Description

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.

Attachments

Change History

comment:1 Changed 10 years ago by solj

  • Status changed from new to closed
  • Resolution set to wontfix

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.

comment:2 Changed 10 years ago by https://www.google.com/accounts/o8/id?id=AItOawkPb0RtPyicSdU7pLcv1UrX-yCh-YjkOwU

  • Status changed from closed to reopened
  • Resolution wontfix deleted

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.

comment:3 follow-up: ↓ 4 Changed 10 years ago by 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.

comment:4 in reply to: ↑ 3 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by solj

  • Milestone changed from Bcfg2 1.2.0 Release to Bcfg2 1.3.0 Release

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

comment:6 Changed 9 years ago by https://www.google.com/accounts/o8/id?id=AItOawnSjgovXZr-_V3vGkvMSR0pc5LDykRc1Nc

  • Status changed from reopened to closed
  • Resolution set to wontfix

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

comment:7 Changed 7 years ago by Richardheef

  • Version 1.0 deleted
  • Milestone Bcfg2 1.3.0 Release deleted

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.

WARNING! You need to establish a session before you can create or edit tickets. Otherwise the ticket will get treated as spam.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.