Replace optparse with argparse

[bdbaddog]

This issue was originally created at: 2011-05-14 12:03:44.
This issue was reported by: ipatrol.

ipatrol said at 2011-05-14 12:03:44

Argparse is more flexible and can be easily configured to use various command conventions, and its type system makes integration with SCons much easier. I am willing to provide a patch myself if no one has any objections to the change.

ipatrol said at 2011-05-14 12:29:10

Here are some open bugs that either demonstrate obstacles to implementation or themselves would be fixed if this change is implemented.

garyo said at 2011-05-15 05:21:58

This is a good idea and a patch would be welcome; however back-compatibility is important for SCons. SCons needs to be compatible back to 2.3, so either argparse has to be back-ported and included in the SCons.compat package (any idea how easy that would be?) or we'd have to wait to include it until a future release which would only be compatible back to 2.7, which may be quite some time.

ipatrol said at 2011-05-15 08:09:30

If you look on PyPi, there is an argparse backport, but my original suggestion was to only use argparse, but my original suggestion was to only make the change for 2.7<= builds. Hence I am adding a floor2.5 keyword because the difficulties of application increase exponentially with each version. I myself would consider it prudent to terminate support to 2.3 and 2.4, but if there are problems with that, pypreprocessor can allow variants of code to execute on different builds for different versions. I am already working on the rewrite though, it should be simple.

dirkbaechle said at 2014-04-27 03:52:51

*** Issue 2946 has been marked as a duplicate of this issue. ***

More information about this issue is at http://docs.python.org/library/argparse.html.

ipatrol said this issue depends on #2064 at 2011-05-14 12:29:10.

ipatrol said this issue depends on #2748 at 2011-05-14 12:29:10.

ipatrol said this issue blocks #2687 at 2011-05-14 12:29:10.

ipatrol said this issue blocks #2375 at 2011-05-14 12:29:10.

dirkbaechle said this issue is duplicated by #2946 at 2014-04-27 03:52:51.

[mwichmann]

Just to note, this isn't actually going to be a trivial uplift (one of the duplicate bugs of this one had originally added the "easy" tag to it). scons reaches inside optparse, including subclassing one class in order to override the method for parsing long opts - an override which ends up missing some things, by the way - and the way that happens in argparse is quite different. It also depends pretty heavily on the Option and OptionGroup classes in optparse, which don't have direct equivalents in argparse. Probably won't be terribly difficult, but it will require some care and some study of both Python modules.

[mwichmann]

Hmmm, it looks like there may be some real value in this: several of the problems we have with option parsing are due to having to do things now-and-later: up front for cmdline stuff, and later, when we get to reading sconcripts, to pick up AddOptions (or interactive option stuff in interactive mode). Current code uses a trick which overrides the parser with one that doesn't fail on options that may have been on the cmdline but are not yet known - but still gets some things wrong. argparse has a function specifically for that purpose: parse_known_args, I'm guessing that will help.

[mwichmann]

Many months later, the previous comment is wrong; yes we will no longer have to override a method in the parser to ignore unknown options, and we don't have to override things to add the nargs='?' usage because that's standard in argparse, but the ordering problem would remain.

anyway, @bdbaddog can you update some details, like the subject line? neither 3.2 nor 2.7 are interesting Python versions any longer...

[bdbaddog]

Many months later, the previous comment is wrong; yes we will no longer have to override a method in the parser to ignore unknown options, and we don't have to override things to add the nargs='?' usage because that's standard in argparse, but the ordering problem would remain.

anyway, @bdbaddog can you update some details, like the subject line? neither 3.2 nor 2.7 are interesting Python versions any longer...

done