conditional inheritance ?

[euri10]

with inheritance I can declare a common set of arguments for various subcommands like so:

class CommonFooBar1:
    s: Annotated[str, cappa.Arg(short=True, long=True)]
    i: Annotated[int, cappa.Arg(short=True, long=True)]


@dataclass
class CommandFoo(CommonFooBar1):
    ...


@dataclass
class CommandBar(CommonFooBar1):
    ...


@dataclass
class Example:
    subcommand: Annotated[CommandFoo | CommandBar, cappa.Subcommand]


def main():
    asyncio.run(  # pragma: no cover
        invoke_async(
            Example,
        )
    )


if __name__ == '__main__':
    main()

Now I'd like to still have CommandFood and CommandBar subcommands, but they would inherit from CommonFooBar1 if an argument switch is set to 1 and from CommonFooBar2 if it is set to 2.

@dataclass
class CommonArgsSwitch:
    switch: Annotated[Literal[1, 2], cappa.Arg(short=True, long=True)]

would that be possible ?

Maybe the more generic question would be the same as what is achievable in this SO question ablout click:
https://stackoverflow.com/questions/55584012/python-click-dependent-options-on-another-option

[DanCardin]

I dont see how this could work in a way that relies on runtime decided conditional inheritance. The parser needs to know ahead of time which options are actually available in order to parse them and to generate --help text.

---

Functionally, It really depends on the details of the alternate base that you're envisioning. If CommonFooBar1 and CommonFooBar2 have identical flag names, and it's "just" a matter of a different parsing interpretation, then today I do have a "discriminated union" test case: https://github.com/DanCardin/cappa/blob/main/tests/arg/test_discriminated_union.py, but that's essentially leading to a single argument being parsed in a particular way, not multiple subsets of arguments.

With this you could get UX like --switch 1 foo and --switch 2 2, where the 2nd arg to the flag would be parsed differently based on the 1st arg's value.

---

If the intent is that they have different flag names, then that's more complicated and confusing. As i said originally, the flags for both options ultimately need to exist at parse time, before you've encountered any options at all (at least from a --help generation and mapping-to-the-output-object` perspective.

While it doesn't exist now, I could imagine there being a feature that makes (more ergnonomic) certain combinations of argument values tied to some other input value, although it's not clear to me right now what that syntax might look like.

You could probably emulate it today through some sort of custom action

from cappa.parser import ParseContext

def two_action(context: ParseContext):
    if 'switch' not in context.result:
        raise ValueError("--switch must be provided before whatever this arg is")
    value = context.result['switch']
    if value == '1':
        raise ValueError("--switch 1 is incompatible with this flag")
    ...

class Foo:
    foo: Annotated[... | None, cappa.Arg(action=two_action)] = None
    bar: Annotated[... | None, cappa.Arg(action=one_action)] = None

or something to that effect. But notably the fields for the alternate flags would both need to exist.

[euri10]

If the intent is that they have different flag names, then that's more complicated and confusing. As i said originally, the flags for both options ultimately need to exist at parse time, before you've encountered any options at all (at least from a --help generation and mapping-to-the-output-object` perspective.

yep this is what I was thinking of.

you know, in fact, your original question ultimately just sounds like more subcommands tbh...like the way you get different downstream subsets of arguments is subcommands

it probably wouldnt work today, but i could imagine a Annotated[tuple[Literal[1], str], Subcommand[CommandFoo, CommandBar]] | Annotated[tuple[Literal[2], str], Subcommand[CommandFoo2, CommandBar2]].

Which wouldnt be a --switch, like your request, but would at least translate into 1 foo and 2 foo mapping to different downstream parse contexts.

I think that is exactly what I want (bare the switch but it's more the conditional effect I'm interested in ie having a different set of options when choosen, hopefully it makes sense)

In my example CommonFooBar2 would be totally different from CommonFooBar1 indeed and depend on the "switch" chosen, but the commands stay the same.

class CommonFooBar1:
    s: Annotated[str, cappa.Arg(short=True, long=True)]
    i: Annotated[int, cappa.Arg(short=True, long=True)]
class CommonFooBar2:
    b: Annotated[bool, cappa.Arg(short=True, long=True)]
    f: Annotated[float, cappa.Arg(short=True, long=True)]

the reason I called this conditional inheritence is that I somehow solved the DRY issue of CommonFoo and CommonBar (I have like 12 commands with the very same options) command through inheritence, but failed on finding a way for the "conditional" or switch effect

I'm happy if it doesnt work through a --switch to be fair, and it would be a killing feature imho

[DanCardin]

you know, in fact, your original question ultimately just sounds like more subcommands tbh...like the way you get different downstream subsets of arguments is subcommands

it probably wouldnt work today, but i could imagine a Annotated[tuple[Literal[1], str], Subcommand[CommandFoo, CommandBar]] | Annotated[tuple[Literal[2], str], Subcommand[CommandFoo2, CommandBar2]].

Which wouldnt be a --switch, like your request, but would at least translate into 1 foo and 2 foo mapping to different downstream parse contexts.

[DanCardin]

is my 2nd code block suggestion of just having the command not be itself a subcommand not workable?

[euri10]

sorry yeah it would be totally fine I think, I guess 1st option would be a little bit more flexible in some cases where you'd want not exactly the same args, but option 2 solves my use case I think (is it a weird silly use case 🧌 ?)

[DanCardin]

I dont think it's silly, the desired interface is the desired interface 🤷.

You could implement my 2nd code block right now and it would be very DRY, the main caveat is that it requires all the commands have identical sets of options at the CLI parser level.

Unfortunately, the moment you want even 1 additional arg/option that shouldnt be available for other commands, you're sort of forced back into subcommands (and your --help would end up changing, even if the literal typed command didnt need to change at all)

But that flexibility that you get from the individual subcommand variant, is also what makes it more verbose 🤷

[DanCardin]

Something else that just occurred to me again, is that Subcommands[A, B] == Annotated[A | B, Subcommand()] and Subcommand() is short for Subcommand(options={'a': Command(...), 'b': Command(...)})

So you can get more custom/fancier by actually supplying your own options to overrride the default behavior.

This is a fully contained example you could run to see if it gives you the desired behavior. And you can then lean more into or further out of the DRY ness as needed.

from __future__ import annotations

from dataclasses import dataclass
from typing import Annotated

import cappa


@dataclass
class Command:
    website: cappa.Subcommands[Google | Bing]


@cappa.command()
class GoogleArgs:
    start: int
    end: int


@cappa.command()
class BingArgs:
    not_start: int
    not_end: int


@cappa.command()
class Ingest:
    """The ingest command."""


@cappa.command()
class Migrate:
    """The migrate command."""


def make_options(variant, *commands):
    variant_command = cappa.collect(variant)
    return {cmd.__name__.lower(): variant_command for cmd in commands}


@cappa.command()
class Google:
    command: Annotated[
        Ingest | Migrate,
        cappa.Subcommand(options=make_options(GoogleArgs, Ingest, Migrate)),
    ]


@cappa.command()
class Bing:
    command: Annotated[
        Ingest | Migrate,
        cappa.Subcommand(options=make_options(BingArgs, Ingest, Migrate)),
    ]


cmd = cappa.parse(Command)
print(cmd)

[euri10]

wahoo @DanCardin this is very beautiful.
I just tested it and it seems to fit 100% of my needs. I still need to step into a debugger and understand better how this make_options works but this looks beautifully promising: much appreciated like the rest of ths amazing library 💌

[euri10]

ok I spoke too fast or I'm missing something obvious, taking your example and adding some invoke functions I get this error when I call google ingest 1 2, the help works fine but the invoke resolution seem to fail.

I added a invoke function to GoogleArgs for instance (in fact the leaf command) and I get the args passed correctly, but I'm unable to say it was from migrate or ingest

from __future__ import annotations

import asyncio
from dataclasses import dataclass
from typing import Annotated

import cappa


@dataclass
class Command:
    website: cappa.Subcommands[Google | Bing]


async def google(args: GoogleArgs):
    print(args)


@cappa.command(invoke=google)
class GoogleArgs:
    start: int
    end: int


@cappa.command()
class BingArgs:
    not_start: int
    not_end: int


@cappa.command()
class Ingest:
    """The ingest command."""


@cappa.command()
class Migrate:
    """The migrate command."""


def make_options(variant, *commands):
    variant_command = cappa.collect(variant)
    return {cmd.__name__.lower(): variant_command for cmd in commands}


@cappa.command()
class Google:
    command: Annotated[
        Ingest | Migrate,
        cappa.Subcommand(options=make_options(GoogleArgs, Ingest, Migrate)),
    ]


@cappa.command()
class Bing:
    command: Annotated[
        Ingest | Migrate,
        cappa.Subcommand(options=make_options(BingArgs, Ingest, Migrate)),
    ]


def main() -> None:
    asyncio.run(  # pragma: no cover
        cappa.invoke_async(
            Command,
        )
    )


if __name__ == "__main__":
    main()

[euri10]

seems like this is working:

from __future__ import annotations

import asyncio
from dataclasses import dataclass
from typing import Annotated

import cappa


@dataclass
class Command:
    website: cappa.Subcommands[Google | Bing]


@dataclass
class GoogleArgs:
    start: Annotated[int, cappa.Arg(short=False, long=True)]
    end: Annotated[int, cappa.Arg(short=False, long=True)]


@dataclass
class BingArgs:
    not_start: int
    not_end: int


async def ingest_google(args: GoogleArgs):
    print(f"Ingesting...{args}")


async def ingest_bing(args: BingArgs):
    print(f"Ingesting...{args}")


@dataclass
class Ingest:
    """The ingest command."""


async def migrate_google(args: GoogleArgs):
    print(f"Migrating...{args}")


async def migrate_bing(args: BingArgs):
    print(f"Migrating...{args}")


@dataclass
class Migrate:
    """The migrate command."""


def make_options(variant, *commands):
    variant_command = cappa.collect(variant)
    options = {
        cmd[0].__name__.lower(): cappa.Command(variant_command.cmd_cls, invoke=cmd[1])
        for cmd in commands
    }
    return options


@cappa.command()
@dataclass
class Google:
    command: Annotated[
        Ingest | Migrate,
        cappa.Subcommand(
            options=make_options(
                GoogleArgs, (Ingest, ingest_google), (Migrate, migrate_google)
            )
        ),
    ]


@cappa.command()
@dataclass
class Bing:
    command: Annotated[
        Ingest | Migrate,
        cappa.Subcommand(
            options=make_options(
                BingArgs, (Ingest, ingest_bing), (Migrate, migrate_bing)
            )
        ),
    ]


def main() -> None:
    asyncio.run(  # pragma: no cover
        cappa.invoke_async(
            Command,
        )
    )


if __name__ == "__main__":
    main()

would be easier to be able to do :

async def ingest(args: GoogleArgs | BingArgs):
    print(f"Ingesting...{args}")

but I failed at making it work, seems like union is not a thing,

[DanCardin]

I think perhaps you're on the right track, if this is still the right solution. You could define them as methods on the object, def bing(self, args: BingArgs): kinda deal, then just make make_options set things up assuming the given interface?

it's still an odd usecase i'm trying to wrap my head around what makes sense and what doesnt as far as the resultant object heirarchy goes and how/where the subcommand value would need to be stashed

[euri10]

it's still an odd usecase i'm trying to wrap my head around what makes sense and what doesnt as far as the resultant object heirarchy goes and how/where the subcommand value would need to be stashed

hehe I myself was just trying to say that when I said above it was maybe a weird silly usecase,
in any case it enabled me to understand better the flow of things in the library and the options is like black magic 🖤

I have possibly another weird use case with args , but this is the same spirit, args defaults depending on other args passed and I think the issue may be the same ie runtime known stuff.

I think perhaps you're on the right track, if this is still the right solution. You could define them as methods on the object, def bing(self, args: BingArgs): kinda deal, then just make make_options set things up assuming the given interface?

I'll try that, this is helpful thanks !