-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support click.option with default values / optional arguments #549
Comments
How would you know if |
I had a similar issue.
Then you can look up the defaults in default_dict - and compare to what you received. |
@untitaker ordering. first comes first served. |
could this be merged if unit tests are added to #548? this is a feature i'm often missing from click... is there a way to monkeypatch our way around this limitation? |
The thing here is that there is no way to tell if an option was entered by a user or if the default value has been used. A user-entered option that has the same value as the default is the same as a non user-entered option with a default. As a result, the simple nargs='?' pattern in argparse cannot be implemented and instead two options must be used: a flag and a value. See https://gist.github.com/pombredanne/aeab7f5b4783919dfe5265b2c553cdb8 for some examples. Not having this capability makes a CLI bloated with more options for no good reason IMHO when wanting to use this approach |
@pombredanne argparse provides a
So @untitaker I honestly don't think its an issue (do what @anarcat said), but you can get around this by not having a space after short options (e.g.
This is a feature I'm missing badly too. It's keeping me from switching my CLI program from argparse. |
@untitaker would you like to see this in Click or not? |
How does Click conform to say the POSIX command line argument syntax standard without supporting optional option-arguments? |
@mbrancato which POSIX standard? could you link to or quote the relevant section? oh no, you can't, because IEEE standards are behind paywalls... :p i mean i'm all for implementing this feature, but heralding POSIX here does not further the discussion.. I think the only thing that needs to happen is to complete unit tests in #548 and make sure they suffice for this issue to be fixed. @mbrancato you wrote that code, i guess it was to resolve this issue? how does your code resolve the following ambiguities?
|
Excuse me, how does it not conform to those conventions? |
Click doesn't support the |
Conforming to a convention does not mean that it has to fully exercise all rights. I can conform to a protocol without using all of its features |
The document specifies a well defined behavior for
I don't understand the resistance. Also, to clear up any confusion as what 'conform' means:
But I guess such utilities could use a subset of the features and still comply/conform/whatever. I personally don't care whether it conforms or not. It's just a useful feature that I would like to have. |
I am willing to chip in a PR. I had to create quirky option subclasses to handle this in a brittle way ;) And I options with a default that is activated only if the option is selected is a bit more than nice to have for me (FWIW, this is how one of my more fleshed out CLI help looks like: https://github.com/nexB/scancode-toolkit/blob/develop/tests/scancode/data/help/help.txt ) |
Click conforms because the synopsis will never show this, because click doesn't support the feature. Your second quote does not support your argument. The suggestions in both the guideline and in this thread to resolve the parsing ambiguity are not good UX imo. I don't really know why anybody needs this feature. Why not have two options? |
Here are two examples of how I use this feature with the argparse module. I have a another example is a |
My use cases are different but resort to the same. For instance I have plugins that contribute various output format options. If one such option is selected (e.g. |
Here is an example. I have a password generator that can be used for generating symbolic (default) or word-based passwords of varying length. With argparse, it looks like this
In Click, the synopsis would be a bit more cluttered and you have to code in that
|
@untitaker re
When you start to have two options for most options and have quite a few options, this is doubling the number of options and gets you an ugly UX & help very quickly, guaranteed to confuse your users together with less explicit, and more verbose code with a lot of boilerplate for no good reasons IMHO. Now leaving aside POSIX, the doc example is to build a git clone. This would not actually be possible with Click as it is: for instance |
regarding @anarcat #549 (comment) - The POSIX thing was mostly off the top of my head, just thinking about other drivers / compatibility. But my code was a simple implementation, it needs significant work to resolve ambiguities. I think there are some ways to solve ambiguities by defining an order preference. Ignoring the space issue causing ambiguities between options and optional arguments, does click support something like the following with three separate results to provide similar functionality as
|
I really need this feature. I'm developing a CLI and I want to write results to stdout by default and use an option to write a file instead of write to stdout, but I want to specify a path or use a default one when no path is specified. For example:
I have found a workaround: |
This comment has been minimized.
This comment has been minimized.
Prior to now, the logic for assigning an option value based on the remaining arguments on the command line has been handled directly by OptionParser. This refactor accomplishes two things: 1: Bringing two very similar procedures into a single method; 2: Placing them in an Option class that can be easily inherited. This clears the way for users or plugins to easily address pallets#549 without affecting core code.
Prior to now, the logic for assigning an option value based on the remaining arguments on the command line has been handled directly by OptionParser. This refactor accomplishes two things: 1: Bringing two very similar procedures into a single method; 2: Placing them in an Option class that can be easily inherited. This clears the way for users or plugins to easily address pallets#549 without affecting core code.
Add a new attribute/argument `explicit_only` to `Option` class. When set to true, this option will cause Options with nargs=1 to only accept input that is explicitly associated to it. This makes the following valid: command command --option command --option=value This addresses pallets#549 and pallets#764.
This comment has been minimized.
This comment has been minimized.
Allow to have flags with optional value. Closes pallets#549 Closes pallets#548 Closes pallets#764
Since the default value always applies, there should be a way to differentiate between the following options usage:
file.py
file.py --foo
file.py --foo 2
where '2' is an argument to --foo. This should produce 3 different values for the destination of 'foo'. This is implemented in argparse with nargs='?' but has no functional equivalent in click (that I can identify). I've created a pull request that implements a potential solution. I'm not asking for a specific way of implementing the solution, and what I provided is mostly for a functional example. It does need test cases.
#548
The text was updated successfully, but these errors were encountered: