Options for template commands

Asked by Javier Collado

Hello,

I've a script that parses some arguments and options with the argparse library that I would like to use as a quickly command in a template. Unfortunately, it seems that, despite quickly passes the arguments correctly to the script, all the options passed are consumed by quickly itself instead of passing them to the command.

Is there any way to pass options to a command?

Best regards,
    Javier

Question information

Language:
English Edit question
Status:
Expired
For:
Quickly Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Didier Roche-Tolomelli (didrocks) said :
#1

Yeah, this is some kind of tricky question, because:

- we want to have the process as smoothed as possible
- we want to be able to check options passed to command
- some option can be in quickly and in the launched software (think about --verbose for instance).

So, how can we achieve that?
* add -- option to quickly run to ignore all option after this -- seperator and pass it directly to the sub command
quickly run -- --option_only_for_programm
* don't check for known option:
- first drawback: if an unknown option is given (mistype --staging in --stagin for instance), it will ignore it and nothing will warn the user about the bad option usage.
- second issue: in case of common option like --verbose, we have to make some choice, like: "all quickly options must be before the first command".
So:
"$ quickly --staging package" will work and "$ quickly package --staging" won't work (after a template command).

I guess the first option is the more reasonable. What do you think about it?

Oh, btw, as a workaround, you can execute bin/yourproject -<whatever options you like> :)

Revision history for this message
Javier Collado (javier.collado) said :
#2

Hello,

I think it would be clearer to have something like this:
$ quickly <quickly-flags> command <command-flags>

Right now I believe quickly flags can be passed anywhere in the command line in favour of flexibility, however I sometimes find this more confusing than an advantage since there are multiple ways to do the same thing.

Best regards,
    Javier

Revision history for this message
Didier Roche-Tolomelli (didrocks) said :
#3

That was my second proposition. I have no strong opinion about it. It can make sense but it's a little bit cluttering to have, for instance :
$ quickly --verbose run --verbose
no ?

I'll ask for rick's opinion too so that we can decide which between option #1 or #2 is the best (in any case, the two solutions are just 3 lines code change, so, no technical difficulties there).

Just as a side note, bzr-buildpackage, pbuilder and others use -- to separate their options to those dedicated to the subcommand.

Revision history for this message
Javier Collado (javier.collado) said :
#4

Thanks for your prompt responses.

Yes, the double verbose example is certainly not desirable. However it seems that this may also happen when using '--' as a separator. Is that correct?

$ quickly --verbose -- run --verbose

Anyway, my preference isn't also really strong. Since both solutions would solve the problem of passing options to commands, the one that you feel it matches better the application would be fine.

Revision history for this message
Didier Roche-Tolomelli (didrocks) said :
#5

actually, it would be:

$ quickly --verbose run -- --verbose
So, we still have two "verbose" instances but I just find that stating explicitly -- is more clear that we stop "quickly options" and switch to "command options".

Again, we will see when Rick will be awaken :)

Thanks for your notice and your constructive proposals.
This issue was on my todo for a long time but I didn't take the time to think about it.

Would be great to have one of these solution for karmic in any case.

Revision history for this message
Didier Roche-Tolomelli (didrocks) said :
#6

Well, thinking about it, not using -- will be better for template options too…
so:
$ quickly <quickly core option> command <template options>

in case of command == run in ubuntu-project project, for instance, it'll give any unknown options and args to applications…

Well, this can break my completion too (removing options proposal once command is given), I have to give further testing…

Revision history for this message
Launchpad Janitor (janitor) said :
#7

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Revision history for this message
Didier Roche-Tolomelli (didrocks) said :
#8

For your information, I've just deactivate the check in Quickly 0.2.5

We have to discuss at UDS about this issue and how to handle it in a proper way.