Hi we have encountered the following problem. We were trying to profile click-enabled application on windows platform in PyCharm. Profiling the is done using a wrapper that deletes itself from the sys.argv array like this:

del sys.argv[0] exec(our_program)

This works on unix platform but not on windows because in def get_os_args() function the parameters are not read from sys.argv as is the standard but rather from _get_windows_argv() and thus the deletion of the first item from argv is not being applied. Would it be possible to fix it?

Perhaps I'm missing something, but I can't find a way to create mutually exclusive option groups in Click. For example, I have a command that can take input from either a socket or a file, and I'd like the following syntax:

cmd [-file <filename> | -stream <address>] ...

At most one (or, in other examples, exactly one) of the options may be specified. Specifying more than one is a parse error caught by the library.

Is it possible to implement this in click at present? If not, would it be feasible to add it? I've not quite got my head around the general architecture yet. Would this feature be a reasonable fit, or does it go against the overall design in some way I've missed?

When the output of a click program is sent to another program via a pipe, and the pipe is closed prematurely, click.echo() was printing an exception backtrace instead of silently exiting like most command line utilities.

Fixes: https://github.com/pallets/click/issues/625

It seems that with 7.0 the longest option argument isn't being used as the internal and variable name.

https://github.com/pallets/click/blob/2c622eed402c64e1645db3904c2410f6c05fbf19/docs/parameters.rst#L93-L95

the internal name is generated automatically by taking the longest argument

import click
import click.testing


print(click.__version__)

@click.command()
@click.option(
    '--temp',
    '--temporary',
    'temporary',
)
def good(temporary):
    pass


@click.command()
@click.option(
    '--temp',
    '--temporary',
)
def bad(temporary):
    pass


def click_runner(command):
    print(command.name)
    runner = click.testing.CliRunner()
    result = runner.invoke(
        command,
        [],
        catch_exceptions=False,
    )
    print(result.output)

click_runner(command=good)
click_runner(command=bad)

https://repl.it/@altendky/click-67-unexpected-keyword-argument-1

6.7
good

bad

https://repl.it/@altendky/click-70-unexpected-keyword-argument-1

7.0
good

bad
Traceback (most recent call last):
  File "python", line 37, in <module>
  File "python", line 32, in click_runner
TypeError: bad() got an unexpected keyword argument 'temp'

https://repl.it/@altendky/click-2e856a5-unexpected-keyword-argument

7.0
good

bad
Traceback (most recent call last):
  File "python", line 37, in <module>
  File "python", line 32, in click_runner
TypeError: bad() got an unexpected keyword argument 'temp'

When you create a command with a setuptools console_scripts entry_points (for instance named mycli) the Usage displayed on POSIX (Linux, Mac,...) when running mycli --help will be: Usage: mycli

In contrast on Windows, I get the following: Usage: mycli-script.py

This is annoying because the correct invocation on windows is to use mycli, not mycli-script.py. The script is the same on all OSes, even though behind the scenes setuptools creates:

• on posix, a bin/mycli python script with a correct shebang
• on windows, a Scripts/mycli-script.py and Scripts/mycli.exe. This is called by invoking mycli like on POSIX

The obvious way to force this would be to use the name arg in click.command. ("This defaults to the function name."). But it does not default to the function name and always show the mycli-script.py instead of mycli.

It looks like this comes from Context.info_name which is computed somehow, but I could not find a way to get this info_name forced to something fixed.

What are your thoughts on shared argument support for click? Sometimes it is useful to have simple inheritance hierarchies in options for complex applications. This might be frowned upon since click's raison d'etre is dynamic subcommands, however, I wanted to explore possible solutions.

A very simple and trivial example is the verbose example. Assume you have more than one subcommand in a CLI app. An ideal user experience on the CLI would be:

python script.py subcmd -vvv

However, this wouldn't be the case with click, since subcmd doesn't define a verbose option. You'd have to invoke it as follows:

python script.py -vvv subcmd

This example is very simple, but when there are many subcommands, sometimes a root support option would go a long way to make something simple and easy to use. Let me know if you'd like further clarification.

After updating Theano from 0.7.0 to 0.8.2 I'm getting the following error:

Exception TypeError: TypeError("'NoneType' object is not callable",) in <bound method _NonClosingTextIOWrapper.del of <_io.TextIOWrapper encoding='UTF-8'>> ignored

Tested with Click 5.1 and 6.6 on Python 2.7.11.

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

I was trying to use supervisor to start an application that uses click and I got this

 raise RuntimeError('Click will abort further execution '
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Either switch to Python 2 or consult http://click.pocoo.org/python3/ for mitigation steps.
Traceback (most recent call last):
  File "/mnt/store/www/apps/inet/pyenv/bin/inetserver", line 11, in <module>
    sys.exit(main())
  File "/mnt/store/www/apps/inet/pyenv/lib/python3.4/site-packages/click/core.py", line 700, in __call__
    return self.main(*args, **kwargs)
  File "/mnt/store/www/apps/inet/pyenv/lib/python3.4/site-packages/click/core.py", line 655, in main
    raise RuntimeError('Click will abort further execution '
RuntimeError: Click will abort further execution because Python 3 was configured to use ASCII as encoding for the environment. Either switch to Python 2 or consult http://click.pocoo.org/python3/ for mitigation steps.

I tried setting the locale using

Supervisor

environment = LC_ALL="en_US.utf-8", LANG="en_US.utf-8" 

Bash

$ export LC_ALL="en_US.utf-8"
$ export LANG="en_US.utf-8"

All to nothing. Note that I am using a virtualenv and python3.4

• fixes #2227

I've tried the fix suggested in the issue above by @Dreamsorcerer, and it seems to fix the typing issue locally.

Checklist:

• [ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
• [ ] Add or update relevant docs, in the docs folder and in code.
• [ ] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
• [ ] Add .. versionchanged:: entries in any relevant code docs.
• [x] Run pre-commit hooks and fix any issues.
• [x] Run pytest and tox, no tests failed.

Sometimes the output machinery embedded in click is not desirable. At least the function that performs write should be customizable to give a user a chance to handle and process all errors that may happen.