passing argument to jugscript

[Semyeong Oh]

Is it possible to pass command line argument to a jugscript?

e.g., `jug execute jugscript.py arg1 arg2 --arg3 value`

and inside `jugscript.py` I have `argparse.ArgumentParser` to parse arguments.

[Luis Pedro Coelho]

Hi Semyeong.

Unfortunately, in the current version arguments ("arg1 arg2") are fine,
but options ("--arg3 value") do not work.

Another user once proposed a solution, but I cannot find the relevant
email right now and no patch materialized. I suppose this is a low
priority for me personally, but I would accept a patch (if it works on
all versions which jug supports).

HTH
Luis

Luis Pedro Coelho | EMBL | http://luispedro.org
My blog: http://metarabbit.wordpress.com

> --
> You received this message because you are subscribed to the Google Groups
> "jug-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jug-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Aaron Goodman]

Hi Luis and Semyeong,

I had a solution that fixed that, but ended up breaking some of the other argument passing abilities to the main jug script. It worked fine for my needs, but I never made a general, non-breaking solution.

The pull request is here if you want to look into it:

https://github.com/luispedro/jug/pull/37/commits/b3835011e939bdc42eb4118dd44bafca37130706

[Luis Pedro Coelho]

> I had a solution that fixed that, but ended up breaking some of the other
> argument passing abilities to the main jug script. It worked fine for my
> needs, but I never made a general, non-breaking solution.
>
> The pull request is here if you want to look into it:
> https://github.com/luispedro/jug/pull/37/commits/b3835011e939bdc42eb4118dd44bafca37130706

In the meanwhile, the argument handling code has changed due to a patch
by Renato (CCed), including a change to argparse, so it may be easier to
do this type of processing now.

HTH,
Luis

--

> > > email to jug-users+...@googlegroups.com <javascript:>.

[Renato Alves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

(Re-sending as the message got bounced back from my other email)

Hi everyone,

Indeed with the new parser this would be a one-line fix, by using `parse_known_args` instead of `parse_args` as per:
https://docs.python.org/2.7/library/argparse.html#argparse.ArgumentParser.parse_known_args

However as seen on the documented example, there are some usage pitfalls which are likely to confuse users.
Jug would also need to warn the user if any unknown arguments are seen since this could simply be due to a typo.

Perhaps a more resilient alternative would be to have something like `--userargs '--arg1 arg --arg2'` as part of 'execute' arguments.

If you are using the latest jug (from git - still unreleased) you can even expand 'execute' yourself by adding the following to `~/.config/jug/jug_user_commands.py`

from jug.subcommands.execute import ExecuteCommand

class MyExecute(ExecuteCommand):
"Custom execute with additional arguments"
name = "myexecute"

def parse(self, parser):
super(MyExecute, self).parse(parser)

parser.add_argument('--myarguments', action='store')

myexecute = MyExecute()


Then call 'jug myexecute --myarguments ...' instead.

This code *abuses* the new subcommands feature at:
http://jug.readthedocs.io/en/latest/subcommands.html#extending-subcommands


You can then add this to your script:

from jug.options import parse
options = parse()

print(options.myarguments)

@Luis, probably turning 'options' into something users can import wouldn't be a terribly bad idea?


Cheers,
Renato

- --
Renato Alves
PhD Student, Bork Group
EMBL-Heidelberg, Germany

Lab Phone: +49 6221 387 8233
Email: renato...@embl.de
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEErWzyn8km9Qx1yUkopwPBKi+mXQQFAljae9MACgkQpwPBKi+m
XQTJuQ/+KX9YxK/2DB2ewxdSfTyvA/Oqz4mgRMMYzJHbWOYGh/Tr02CRCV3zdAhD
NDAuiu7oEN8uOD2fLnU0FXMgBhcvafhVGWr+Uqpi/0O1NQNRerTOotNU3xon8zW1
KQ7Y9sAlMnQrmyvo4cwKjumL60XEC9LOJDspoD9E8dnAZ/DShbHE2rax71qaoVC+
aPSfYn5/fD0V2jUaAmaw8GDgUf5epA4XPbck7e/GHrwF2Z0gV7rThnQ//TUwPVvL
QEeSjCXWqRjxIha9tSj5Tz11Z+e1JqxLJlNDd29Kh+xjGnt6dc7+2Oi32iSWK0HP
Q8TYBLjoBHqRDtUWUrqNYZSU3VOc8UyN7MfBX0ztyZnCz69Jr6YjsZhiiIad65I7
CvMpankNC5QweMv126l9DY/0eug//JY0XDYBlMq+NBv4+2jgAiW1SfLaaAWsE7on
yHcSPBjkG+XhyH9DL9Q98JsohtjkwTnRl3+I2ZPe0O3V+ib0NuYyfdjR+rTHek7p
PdAAkbs05FdD10Piw1HIS5tZaxo7HUK0SAh//MHBteNIOJaOAV+mq4nFgQYlh738
1lWV5QxhNXkG+H/GZhDhYcokRrGenh2cjUloy3GW+jjyQ+e2Kd6PhOBUMY/AYI6y
ukRYY8Qr59f60N1q57NI9/JOoI9VXy3em3/sTb0NX8Xg3Ed8cH0=
=dpSj
-----END PGP SIGNATURE-----

[Luis Pedro Coelho]

I just realized that in the released version, the following works well:

jug execute --aggressive-unload jugfile.py -- --arg1 12 --arg2 "hello"

inside jugfile.py, 'sys.argv' is now:

['jugfile.py', '--arg1', '12', '--arg2', 'hello']

Double-dash terminates jug option parsing. It's slightly verbose, but
it's unambiguous (Explicit is better than implicit).

The git version does not work like this, which is a bug to fix before
release.

> `parse_known_args` instead of `parse_args` as per:
> https://docs.python.org/2.7/library/argparse.html#argparse.ArgumentParser.parse_known_args
>
> However as seen on the documented example, there are some usage pitfalls
> which are likely to confuse users.
> Jug would also need to warn the user if any unknown arguments are seen
> since this could simply be due to a typo.

It would also mean that introducing new arguments to jug could
(potentially) break some script that used that argument as an internal
argument.

> @Luis, probably turning 'options' into something users can import
> wouldn't be a terribly bad idea?

Probably not, but I'm not sure what the API should be. For this
particular use-case, the double-dash solution above seems a workable
response.

Cheers,
Luis