-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Merge Stable into Main #3114
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
Merged
Merged
Merge Stable into Main #3114
+582
−169
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This changes the implementation of the fixes in #1836 and #2093 to address the problem that they created when `click.prompt` or `click.confirm` has a `prompt_suffix` value which is empty. This still fixes the problems reported in #665 and #2092 but does so without modifying the prompt and adding a trailing space. Previously, the problem was solved by trimming all trailing space characters from the prompt and then adding a single trailing space to every prompt. This was only visible if the last character in the prompt wasn't a space character. In those cases a prompt like "This is my prompt" would render as "This is my prompt ". Additionally, in the previous solution, if the `err=True` argument was passed, that final trailing space character that was added would be sent to STDOUT while the rest of the prompt would go to STDERR. This also wasn't very apparent since it was a space character. This different implementation uses the last character of the prompt to work around #665 and #2092 instead of adding a space character. This fixes most of the potentially confusing behavior. It does retain one confusing behavior which is described above, where if you use `err=True` the last character of the prompt is sent to STDOUT instead of STDERR. Previously, this last character sent to STDOUT would always be a space character. Now if the last character of the prompt is not a space character, that final character will go to STDOUT. For example if you call ```python click.prompt("bar", prompt_suffix="", err=True) ``` The `ba` will go to STDERR and the `r` will go to STDOUT. Previously `bar` would go to STDERR and an added ` ` would go to STDOUT. This odd behavior, which is already present but just applies to a space character, is worth accepting so that the `prompt_suffix` correctly renders the suffix as it did in version 7.1.2 and prior. This also adds unit tests for cases where `prompt_suffix` is empty. This fixes #3019
When options are being parsed, multiple options may evaluate to have defaults of `UNSET`, and some may evaluate to have explicitly set defaults of `None`. The normalization of `UNSET -> None` is now deferred until all options have been parsed, so that it is possible to accurately evaluate and save the first non-UNSET default value. A new test exercises this functionality by pointing two flags at the same parameter declaration, and showing that their behavior is not order sensitive when only one of the flags has a default. resolves #3071
Per review feedback: - Remove an extraneous comment - Expand another, more significant comment Co-authored-by: Kevin Deldycke <[email protected]>
This adds details of the change in #3021
In order to ensure that user-defined `type_cast_value` hooks are never called with a value of `UNSET`, it is necessary to intercept `UNSET` values and, in the particular cases in which `UNSET` needs special handling, preempt any call to `type_cast_value()`. `process_value()` is updated to check before calling `type_cast_value` and to skip the call entirely if an `UNSET` value is detected. Passing a value of `None` would not have the same effect for `click.Option`, which previously had logic which is specific to the `value is UNSET` case, and which cannot be reliably detected if a `None` value is passed in. This means that `type_cast_value()` is no longer guaranteed to be called during argument processing, but when it is called, it's guaranteed not to see an `UNSET` value. New tests explore this only from the perspective of checking if `UNSET` is ever passed, not in terms of pinning down when/if the hook gets called. resolves #3069
Programs such as BusyBox, Toybox and Coreutils (also gzib, bzip etc) in multi-call mode derive their identity from the symlink. Resolving the symlink causes them to misbehave.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.