upcxx-run arg validation should stop at first non-option argument

[Dan Bonachea]

Example trace with upcxx-run v2018.9.0:

$ upcxx-run -np 2 hello-world
Hello world from rank 1
Hello world from rank 0

$ upcxx-run -np 2 hello-world -s
usage: upcxx-run [-h] [-n NUM] [-N NUM] [-shared-heap HEAPSZ] [-backtrace] [-show] [-info]
                 [-ssh-servers HOSTS] [-localhost] [-v] [-vv]
                 command ...
upcxx-run: error: ambiguous option: -s could match -shared-heap, -show, -ssh-servers

$ upcxx-run -np 1 gdb -s hello-world    
usage: upcxx-run [-h] [-n NUM] [-N NUM] [-shared-heap HEAPSZ] [-backtrace] [-show] [-info]
                 [-ssh-servers HOSTS] [-localhost] [-v] [-vv]
                 command ...
upcxx-run: error: ambiguous option: -s could match -shared-heap, -show, -ssh-servers

Here the -s is being passed as an argument to the child "command...", but upcxx-run is incorrectly validating it against its own argument rules.

[Paul Hargrove]

I believe the argument parsing does honor -- as a sentinel.
So, the following should work around the reported issue:
$ upcxx-run -np 2 -- ./hello-world -s

[Dan Bonachea]

Workaround confirmed, thanks Paul.

Lowering priority, but we should still fix this before next release.

[Mathias Jacquelin]

I'm a bit puzzled by this. I acknowledge the issue based on your input, but I can use sympack and passing options correctly. The only difference I see is ./ instead of trying to run something from path.

Best,

Mathias Jacquelin Research Scientist Lawrence Berkeley National Laboratory [e-mail] 1-510-495-2605

[Dan Bonachea]

I'm a bit puzzled by this. I acknowledge the issue based on your input, but I can use sympack and passing options correctly.

Mathias: I suspect it only occurs if you pass -s or -sh options to symPack. No other options will trigger upcxx-run's ambiguous argument error.

[Dan Bonachea]

This issue was triaged at the 2019-07-24 Pagoda issue meeting and assigned a new milestone.

[Dan Bonachea]

I've looked into this and determined that it appears to be a bug in Python argparse.

Even using Python 3.4.9 and the argparse.parse_known_args() method that appears to be intended for this scenario, the parser still incorrectly attempts to parse the trailing arguments and whines about them being ambiguous, rather than ignoring the unknown argument as it should.

argparse does not even have a supported mechanism to disable the argument prefix matching until 3.5 - there are some hacks that accomplish the same but I don't think we want to globally disable the convenience provided by prefix matching for our parser in order to solve this corner case which has a known workaround.

IMO this external defect is not worth further effort on our part.

[Paul Hargrove]

Thanks, @Dan Bonachea , for looking into this.

I want to repeat that the recommended work-around is use of -- to terminate python's argument parsing:

$ upcxx-run -np 2 -- ./hello-world -s