Shared args

[Tobi-De]

How do I go about doing this

@dataclass
class BaseCommand:
    host: Annotated[str | None, cappa.Arg(long="--host")]

    def __call__(self, config: ConfigDep):
        if self.host:
            try:
                host = config.hosts[self.host]
            except KeyError as e:
                raise cappa.Exit(f"Host {self.host} does not exist", code=1)
        else:
            host = config.primary_host
        super().__call__(host) # noqa


@cappa.command(help="Run arbitrary command on the server")
class Exec(BaseCommand):

    def __call__(self, config: ConfigDep):
        print(self.host)

The code above does not work, basically I need a host argument that be shared across multiple commands, the input for this is a string (the host name), but it should be parsed into a Host object each time, the option is not required, there is a default host somewhere that should be used if no host is specified

[DanCardin]

I assume the primary_host is not a static/env var? (if so, it could be a default on the cappa class itself)

So the super().__call__(host) would need to be in the Exec impl in order to work properly, as written. at which point it seems to yield the behavior i'd think you would expect.

I would probably personally write it like this:

from dataclasses import dataclass
from functools import cache
from typing import Annotated, ClassVar
import cappa

@dataclass(frozen=True)
class Config:
    primary_host = "primary"
    hosts: ClassVar = {"foo": "foo"}


ConfigDep = Annotated[Config, cappa.Dep(Config)]


@dataclass(frozen=True)
class BaseCommand:
    _host: Annotated[str | None, cappa.Arg(long="--host")]

    @cache
    def host(self, config: ConfigDep):
        if not self._host:
            return config.primary_host

        try:
            return config.hosts[self._host]
        except KeyError:
            raise cappa.Exit(f"Host {self._host} does not exist", code=1)


@cappa.command(help="Run arbitrary command on the server")
class Exec(BaseCommand):

    def __call__(self, config: ConfigDep, output: cappa.Output):
        output.output(f"host: {self.host(config)}")


cappa.invoke(Exec)

Basically just to localize the handling of host here and avoid needing to deal with super at all.

[DanCardin]

Ah, I see. So this is a weird side-effect of vanilla dataclasses. Exec is a subclass of a dataclass, without itself being decorated with @dataclass. E.g. same problem with vanilla dataclasses:

from dataclasses import dataclass

@dataclass(frozen=True)
class BaseCommand:
    host: str | None

class Exec(BaseCommand):
    asdf: int

Exec("host", 4) # error

There's no way for me (that i know of) to detect whether you've decorated your class with @dataclass versus being a subclass, so in this instance (subclassing a dataclass) we can't detect whether we should automatically wrap the class in a dataclass or not.

tl;dr this fixes the issue.

@cappa.command(help="Run arbitrary command on the server")
@dataclass
class Exec(BaseCommand):

Also _host: Annotated[str | None, cappa.Arg(value_name="host", long="--host")] should make --help show the value as "HOST" instead of "_HOST"

[Tobi-De]

Ah, I see. So this is a weird side-effect of vanilla dataclasses

Are you suggesting using something else would fix the issue ? attrs, msgspec etc...

[DanCardin]

It's not an issue per-se, you just need to explicitly decorate subclasses in order for any fields defined on them to be composed into the child dataclass. And generally, dataclasses/attrs/msgspec (afaik) all require you to decorate at least the leaf class (Exec in this case), so i wouldn't expect any of them to fare any better. Pydantic classes would, by virtue of forcing you to subclass BaseModel.

(And cappa infers any unadorned classes as dataclasses and will implicitly dataclass-transform them, which is why your original example was working at all. Just in the case of subclassing, we can't detect the difference between a subclass of a proper dataclass and a class that has been @dataclass'd; whereas if there was no subclassing going on, it would "just work")

EDIT: And in any case, for typing's sake, you're better off explicitly decorating with @dataclass on each class anyways

[Tobi-De]

Ok I get it, I will later try to get rid of the subclass thing when I have something working, thanks again :)

[DanCardin]

There are probably ways around subclassing, to be sure. but to be clear, the subclassing should be fine! It's certainly part of the supported design of cappa. it just requires the explicit dataclass decorator when defining your command is all.