pylint error on decorated `name` argument

pylint error on decorated name argument Due to the way the name argument is injected into some functions with a decorator, such as pyinfra.operations.server.shell, we get a pylint error like:

deploy/deploy.py:3:0: E1123: Unexpected keyword argument 'name' in function call (unexpected-keyword-arg)

To Reproduce deploy.py:

from pyinfra.operations import server

server.shell(
    name='Run command',
    commands=['echo "1234"']
)

pylint deploy.py

Expected behavior No pylint errors

Meta

• System: Linux Platform: Linux-5.8.11-1-MANJARO-x86_64-with-glibc2.2.5 Release: 5.8.11-1-MANJARO Machine: x86_64 pyinfra: v1.2.1 Executable: /home/user/workspace/common/venv/bin/pyinfra Python: 3.8.5 (CPython, GCC 10.2.0)
• pip installed

[Fizzadar]

Hm. I can’t replicate this (the error) with either mypy or pylint; using the following example:

from typing import Generator, List

from pyinfra.api.operation import operation


@operation
def shell(commands: List[str]) -> Generator[str, None, None]:
    for command in commands:
        yield command


shell(
    name="Run command",
    commands=["echo hi"],
    yes=False,
)

This passes with both tools as the decorator seems to effectively disable all type checking on the function args as it interprets them as *args, **kwargs. So this is useless but also should not be raising the original error here?

---

Regarding fixing typing properly in the future I had one idea - we could (ab)use stub files to force type checkers into including all the global arguments as valid types. Ie by generating (possibly as part of package install?) stub files alongside operation files that type annotate the op functions un-decorated; ie:

def shell(
    commands: list[str],
    name: str | None,
    _sudo: boolean = False,
    ...all the other global args,
) -> Generator[Command | str, None, None]: ...

This would a) get around the Python 3.10 requirement for ParamSpec and b) get around ParamSpec’s inability to extend keyword arguments (currently).

Annotations could simply be inlined everywhere in the codebase, including operations, and the stub generator would use these combined with the global arguments to generate stubs for operation modules.

[Fizzadar]

So flake8 doesn’t do type checking which has prevented this being an issue before! There’s currently a PR/branch (https://github.com/Fizzadar/pyinfra/pull/472) tracking implementation of type checking using mypy.

The operation functions are particularly annoying as they all accept a list of global arguments, defined here which is a bit of a nightmare for typing.

I think long run the right approach is to move these into the operation function definition itself, will need to deduplicate that with the deploy function also (possibly by way of a decorator decorator!).