Very much late, but this might help others with the same issue: Click.Command has both a params property and an (undocumented) get_params(ctx) method. The latter method also returns the help option, if one exists.

To access the default values regardless of order of execution, use the following in your callback code:

defaults = {p.name: p.default for p in ctx.command.params}
# To use param values if they exist, uncomment the following line
# defaults.update(ctx.params)

Note that as tmwilson26 correctly noticed, only params which have already been processed by Click will appear in ctx.params.

You are running into problems trying to do this in the callback, because the order in which the callbacks are invoked does not guarantee that all of the parameters you need, will have been evaluated when your callback is invoked.

One way you can do this is to override click.Command.make_context(), and do your validation after the context construction is complete.

Custom Command Class

This function is passed a validator function and returns a custom click.Command class.

def command_validate(validator):

    class CustomClass(click.Command):

        def make_context(self, *args, **kwargs):
            ctx = super(CustomClass, self).make_context(*args, **kwargs)
            validator(ctx)
            return ctx

    return CustomClass

Validator Function

The validator function is passed a context, and can raise a click.BadParameter exception when the validation fails.

def validate_variables(ctx):
    """Check that requested variable(s) are in netCDF file """

    value = ctx.params['variable']
    tile = ctx.params['tile']
    with xr.open_dataset(tile) as ds:
        for v in value:
            if v not in ds.data_vars:
                raise click.BadParameter(
                    'Var %s not in file %s.' % (v, tile), ctx)

Using Custom Class:

To use the custom class, pass command_validate a validator function, and pass the return value as cls to the command decorator like:

@click.command(cls=command_validate(validate_variables), ...OtherOptions...)
...Other config...

As far as I can surmise the only alternatives, from this issue, are to

1. Call the underlying function like main.callback(*args). Then you're missing default arguments from the click interface.

2. To use the click testing interface via something like click.testing.CliRunner().invoke(main, ['--host', '127.0.0.1'], catch_exceptions=False).

I suppose from my point of view, option 1 is the best we can do; default parameters just have to be done manually. I would be curious too if there were any better alternatives though.

The callback is used both to validate the prompt input, and then independently from that is used to validate the value passed to the option (which in this case came from the prompt). Usually this shouldn't matter, but if you're doing something expensive it might. You could omit the prompt from the option, and instead call prompt yourself in the command if the option wasn't given.

I tried with Python 3.7 and Click 7 the following code:

import click

@click.command()
@click.option('-w', '--width', type=int, default=0)
@click.option('--option2')
@click.argument('argument')
def app(width, option2, argument):
    click.echo("params: {} {} {}".format(width, option2, argument))
    assert width == 3
    assert option2 == '4'
    assert argument == 'arg'


app(["arg", "--option2", "4", "-w", 3], standalone_mode=False)

app(["arg", "-w", 3, "--option2", "4" ], standalone_mode=False)

app(["-w", 3, "--option2", "4", "arg"], standalone_mode=False)

All the app calls are working fine!

I would suggest adding a @staticmethod to your Config class to use as the target of the callback like:

Callback Method:

@staticmethod
def click_callback(ctx, param, value):
    getattr(ctx.obj, ctx.obj.func_name)()
    return value

Test Code:

import click

class Config:
    def __init__(self, func_name):
        self.func_name = func_name

    def func_a(self):
        click.echo('Func A')

    def func_b(self):
        click.echo('Func B')

    @staticmethod
    def click_callback(ctx, param, value):
        getattr(ctx.obj, ctx.obj.func_name)()
        return value


@click.group()
@click.option('-f', '--func-name', required=True)
@click.pass_context
def group(ctx, func_name):
    ctx.obj = Config(func_name)


@group.command()
@click.option('--my-option', '-o', callback=Config.click_callback)
def command(my_option):
    click.echo('command: {}'.format(my_option))


if __name__ == "__main__":
    commands = (
        '-f func_a command -o optionA',
        '-f func_b command -o optionB',
        '-f func_a command -o ',
        'command',
        '--help',
        '',
    )

    import sys, time

    time.sleep(1)
    print('Click Version: {}'.format(click.__version__))
    print('Python Version: {}'.format(sys.version))
    for cmd in commands:
        try:
            time.sleep(0.1)
            print('-----------')
            print('> ' + cmd)
            time.sleep(0.1)
            group(cmd.split())

        except BaseException as exc:
            if str(exc) != '0' and \
                    not isinstance(exc, (click.ClickException, SystemExit)):
                raise

Results:

Click Version: 6.7
Python Version: 3.6.3 (v3.6.3:2c5fed8, Oct  3 2017, 18:11:49) [MSC v.1900 64 bit (AMD64)]
-----------
> -f func_a command -o optionA
Func A
command: optionA
-----------
> -f func_b command -o optionB
Func B
command: optionB
-----------
> -f func_a command -o 
Error: -o option requires an argument
-----------
> command
Usage: test.py [OPTIONS] COMMAND [ARGS]...

Error: Missing option "-f" / "--func-name".
-----------
> --help
Usage: test.py [OPTIONS] COMMAND [ARGS]...

Options:
  -f, --func-name TEXT  [required]
  --help                Show this message and exit.

Commands:
  command
-----------
> 
Usage: test.py [OPTIONS] COMMAND [ARGS]...

Options:
  -f, --func-name TEXT  [required]
  --help                Show this message and exit.

Commands:
  command

I have come up with following code, which produces the desired behavior:

def deactivate_prompts(ctx, param, value):
    if not value:
        click.echo("entering batch mode, deactivating all prompts ...")
        for p in ctx.command.params:
            if isinstance(p, click.Option) and p.prompt is not None:
                p.prompt = None
    return value

@click.option('--i/--b', default=True, is_eager=True, expose_value=False, callback=deactivate_prompts)
@click.option('--x', default=42, prompt=True)
@click.command
def cli_c(x):
  print(x)

The idea is to use the callback of an eager option to modify all (other) Options of the Command.

POTENTIAL WEAK POINTS:

• This is an all or nothing solution, i.e. either all of the prompts are active or none. For my use-case, that's exactly what I wanted, but for others that might not be the case.
• This works only in one direction, i.e. by turning the prompts off. So each Option that may or may not display a prompt must be configured as if displaying a prompt.
• If we turn off the prompts, we still need a value for that Option, so an alternate value-source is a must. I.e. a default value must be provided.

When you call add_name() and add_surname() directly from another function, you actually call the decorated versions of them so the arguments expected may not be as you defined them (see the answers to How to strip decorators from a function in python for some details on why).

I would suggest modifying your implementation so that you keep the original functions undecorated and create thin click-specific wrappers for them, for example:

def add_name(content, to_stdout=False):
    if not content:
        content = ''.join(sys.stdin.readlines())
    result = content + "\n\tadded name"
    if to_stdout is True:
        sys.stdout.writelines(result)
    return result

@click.command()
@click.argument('content', required=False)
@click.option('--to_stdout', default=True)
def add_name_command(content, to_stdout=False):
    return add_name(content, to_stdout)

You can then either call these functions directly or invoke them via a CLI wrapper script created by setup.py.

This might seem redundant but in fact is probably the right way to do it: one function represents your business logic, the other (the click command) is a "controller" exposing this logic via command line (there could be, for the sake of example, also a function exposing the same logic via a Web service for example).

In fact, I would even advise to put them in separate Python modules - Your "core" logic and a click-specific implementation which could be replaced for any other interface if needed.