How to properly fix "nargs for store actions must be != 0" error? about argparse HOT 13 CLOSED

Closing?

Seems error is descriptive & exact as in original (not specific to ported code). Our doc says how to update "correct" code, but your one probably had unexpected combination of params (no reported in v1).

from argparse.

after changing the option to

  [['--shell'], {
    required: false,
    defaultValue: false,
    action: 'storeTrue',
    help: 'Enter REPL mode',
    nargs: 0,
    dest: 'shell',
  }],

The following exception is thrown:

/home/travis/build/appium/appium/node_modules/argparse/argparse.js:343
374        throw new TypeError(sub('%s() got an unexpected keyword argument %r',
375              ^
376TypeError: _StoreTrueAction() got an unexpected keyword argument 'nargs'
377    at _parse_opts (/home/travis/build/appium/appium/node_modules/argparse/argparse.js:343:15)
378    at new _StoreTrueAction (/home/travis/build/appium/appium/node_modules/argparse/argparse.js:1459:13)
379    at new _StoreTrueAction (/home/travis/build/appium/appium/node_modules/argparse/argparse.js:205:28)
380    at new deprecated (internal/util.js:87:14)
381    at ArgumentParser.add_argument (/home/travis/build/appium/appium/node_modules/argparse/argparse.js:2154:22)
382    at ArgumentParser.addArgument (internal/util.js:89:15)
383    at getParser (/home/travis/build/appium/appium/lib/parser.js:888:12)
384    at Suite.<anonymous> (/home/travis/build/appium/appium/test/config-specs.js:200:18)
385    at Object.create (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/interfaces/common.js:140:19)
386    at describe (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/interfaces/bdd.js:42:27)
387    at Suite.<anonymous> (/home/travis/build/appium/appium/test/config-specs.js:199:3)
388    at Object.create (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/interfaces/common.js:140:19)
389    at describe (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/interfaces/bdd.js:42:27)
390    at Object.<anonymous> (/home/travis/build/appium/appium/test/config-specs.js:20:1)
391    at Module._compile (internal/modules/cjs/loader.js:1137:30)
392    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
393    at Module.load (internal/modules/cjs/loader.js:985:32)
394    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
395    at Module.require (internal/modules/cjs/loader.js:1025:19)
396    at require (internal/modules/cjs/helpers.js:72:18)
397    at /home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/mocha.js:334:36
398    at Array.forEach (<anonymous>)
399    at Mocha.loadFiles (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/mocha.js:331:14)
400    at Mocha.run (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/mocha.js:809:10)
401    at Object.exports.singleRun (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/cli/run-helpers.js:108:16)
402    at exports.runMocha (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/cli/run-helpers.js:142:13)
403    at Object.exports.handler (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/cli/run.js:292:3)
404    at Object.runCommand (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/yargs/lib/command.js:242:26)
405    at Object.parseArgs [as _parseArgs] (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/yargs/yargs.js:1096:28)
406    at Object.parse (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/yargs/yargs.js:575:25)
407    at Object.exports.main (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/lib/cli/cli.js:68:6)
408    at Object.<anonymous> (/home/travis/build/appium/appium/node_modules/gulp-mocha/node_modules/mocha/bin/mocha:162:29)
409    at Module._compile (internal/modules/cjs/loader.js:1137:30)
410    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
411    at Module.load (internal/modules/cjs/loader.js:985:32)
412    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
413    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
414    at internal/main/run_main_module.js:17:47

Also, it's weird that the actual action dictionary is shown as _StoreTrueAction() in the exception message. It would be much easier to see the actual stringified representation of it

from argparse.

https://github.com/nodeca/argparse/tree/master/doc

Take a look at updated docs & migration info, as advised in changelog. Your code uses old signatures.

Ideally, argparse should throw more descriptive messages what to change. If you can provide minimal executable sample, we will check why that no happens.

from argparse.

Unfortunately the migration doc above does not say anything about nargs. I have experimented with the Python's (3.7.5) module a bit at it looks like it behaves similarly:

parser.add_argument('--shell', nargs=0, default=None, required=False, action='store_true',
                                     help='Enter REPL mode', dest='shell')

....

Traceback (most recent call last):
  File "args.py", line 7, in <module>
    help='Enter REPL mode', dest='shell')
  File "/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/argparse.py", line 1359, in add_argument
    action = action_class(**kwargs)
TypeError: __init__() got an unexpected keyword argument 'nargs'

Removing nargs completely from the arg definition solves the issue

from argparse.

Is the rest of update process ok? If you have ideas about docs improve - let us know or send PR.

from argparse.

Thanks for asking. No, not so easy at all. The reason for that is mostly our own hacks, which were working in v1, before more validation has been added to v2.
For example, we are adding custom properties to actions in order to validate which of the command line flags are deprecated. Now such possibility is prohibited, because of

The other hack we were using is parseArgs method patching: https://github.com/appium/appium/blob/a88f51d70bf39f3860b49ebcc6b1e5a443c83a72/lib/parser.js#L811
This also has stopped working now because the property is changed to read only.

After we find workarounds for the hacks above it would be necessary to validate the command line args are still working, which is a long process looking at the count of them.

In general the code of argparse lib itself is much more cleaner and closer to what Pythonic source is. I also like the count of unit tests written for the actual port. For us, though, the upgrade process to v2 is quite challenging.

from argparse.

May be extend base actions to ActionXxxDeprecated could help. I'm not experienced in argpase use, but all recipes from SO for python should work in v2.

from argparse.

Yeah, this could work. Is there any example in the documentation on how to properly create Action subclass in v2? Does the module export all the necessary primitives to make that possible? As far as I could see the _parse_opts helper, for example, is private.

from argparse.

Also, for our purpose it would make sense to inherit existing actions, like _StoreTrueAction, but this one is also private

from argparse.

Yeah, this could work. Is there any example in the documentation on how to properly create Action subclass in v2?

https://github.com/lvgl/lv_font_conv/blob/master/lib/cli.js here is what we do in our scripts. Everything is ~ the same as in python.

Does the module export all the necessary primitives to make that possible? As far as I could see the _parse_opts helper, for example, is private.

Ported code exports exactly the same as original version. If something is "not available" - probably you try to do wrong things.

from argparse.

Thanks for the hint. I was able to make it working using custom actions (and I also like this approach much more than the previous hacky one). Here are my changes if anybody is interested in the details.

from argparse.

Here are my changes if anybody is interested in the details.

Interested.

You're using action?.deprecated_for syntax, which is node v14 I think? Appium officially supports v8? I'm not sure, but it might be too heavy on new es7 syntax.

and I also like this approach much more than the previous hacky one

You have way too many classes, and all of them do the same exact thing (deprecation).

Custom classes is the right approach, but I'd rather use mixins for this purpose. Something like this:

let argparse = require('./')

let parser = new argparse.ArgumentParser({ prog: 'PROG' })

function DeprecationMixin(action_class) {
  return class DeprecatedAction extends action_class {
    constructor({ deprecated, ...other_opts } = {}) {
      if (deprecated) other_opts.help = `[DEPRECATED: ${other_opts.help}]`
      super(other_opts)
      this.deprecated = deprecated
    }

    // and do whatever else you'd normally do here for deprecations
  }
}

// warning, warning, warning: `_registries` and `_registry_get` isn't public,
// but I don't remember other way to get built-in classes otherwise
for (let action_name of Object.keys(parser._registries.action)) {
  parser.register('action', action_name, DeprecationMixin(parser._registry_get('action', action_name)))
}

parser.add_argument('-a', {
  action: 'store_true',
  help: 'aaaaa',
  deprecated: true
})

console.log(parser.parse_args(['-a']))
console.log(parser.parse_args(['-h']))

Does the module export all the necessary primitives to make that possible? As far as I could see the _parse_opts helper, for example, is private.

I hope so? argparse.js exports the same things as argparse.py exports as __all__. Hmm... actually, no. I guess private classes need to be exposed as well? :/

_parse_opts is just an attempt to simulate python args validation, probably not needed anywhere else (let me know if someone finds it useful, maybe worth a separate package or something).

from argparse.

You're using action?.deprecated_for syntax, which is node v14 I think? Appium officially supports v8? I'm not sure, but it might be too heavy on new es7 syntax.

We use babel to transpile the code plus some experimental options. I suppose in the resulting (transpiled) source this operator is simply replaced with a regular if block. Although, we find it very good to reduce the count of lines and to improve readability. We've also enabled the experiment for ?? (nullish coalescing) operator.

from argparse.