[Request]: Enhance DX for passing down option groups when using a Plugin

[Mcrich23]

Feature or enhancement request details

The principal issue here is that it was decided to not expose any properties of commands for the purposes of Plugin development (see #603). Because of that, passing down OptionGroups can look like the following:

@OptionGroup
var managementFlags: Flags.Management

mutating func run2() async throws {
    var arguments: [String] = ["hello-world"]

    // Expand managementFlags into CLI arguments
    if managementFlags.detach {
        arguments.append("--detach")
    }

    if let entryPoint = managementFlags.entryPoint {
        arguments.append(contentsOf: ["--entrypoint", entryPoint])
    }

    for mount in managementFlags.mounts {
        arguments.append(contentsOf: ["--mount", mount])
    }

    for port in managementFlags.publishPorts {
        arguments.append(contentsOf: ["--publish", port])
    }

    for socket in managementFlags.publishSockets {
        arguments.append(contentsOf: ["--publish-socket", socket])
    }

    for tmp in managementFlags.tmpFs {
        arguments.append(contentsOf: ["--tmpfs", tmp])
    }

    if let name = managementFlags.name {
        arguments.append(contentsOf: ["--name", name])
    }

    if managementFlags.remove {
        arguments.append("--rm")
    }

    if let platform = managementFlags.platform {
        arguments.append(contentsOf: ["--platform", platform])
    }

    arguments.append(contentsOf: ["--os", managementFlags.os])
    arguments.append(contentsOf: ["--arch", managementFlags.arch])

    for vol in managementFlags.volumes {
        arguments.append(contentsOf: ["--volume", vol])
    }

    if let kernel = managementFlags.kernel {
        arguments.append(contentsOf: ["--kernel", kernel])
    }

    for network in managementFlags.networks {
        arguments.append(contentsOf: ["--network", network])
    }

    if !managementFlags.cidfile.isEmpty {
        arguments.append(contentsOf: ["--cidfile", managementFlags.cidfile])
    }

    if managementFlags.dnsDisabled {
        arguments.append("--no-dns")
    }

    for dns in managementFlags.dnsNameservers {
        arguments.append(contentsOf: ["--dns", dns])
    }

    if let domain = managementFlags.dnsDomain {
        arguments.append(contentsOf: ["--dns-domain", domain])
    }

    for search in managementFlags.dnsSearchDomains {
        arguments.append(contentsOf: ["--dns-search", search])
    }

    for option in managementFlags.dnsOptions {
        arguments.append(contentsOf: ["--dns-option", option])
    }

    for label in managementFlags.labels {
        arguments.append(contentsOf: ["--label", label])
    }

    if managementFlags.virtualization {
        arguments.append("--virtualization")
    }

    if managementFlags.ssh {
        arguments.append("--ssh")
    }

    // Now parse with all expanded args
    var createCommand = try Application.ContainerCreate.parse(arguments)
    try await createCommand.run()
}

This also makes it so developers have to manually add support when new options are added rather than just a requirement of recompiling (which is far more likely to speed up adoption in plugins).

To address this issue, I would like to propose the development of a macro that synthesizes a function called asParsableArguments and returns an array of arguments for the option group and can then be passed along when desirable.

Thoughts?

Code of Conduct

• I agree to follow this project's Code of Conduct

[Mcrich23]

Tagging you in this @jglogan

[jglogan]

Thanks for raising the issue! One possible challenge for a macro approach is where a Command transforms its arguments; for example:

• https://github.com/apple/container/blob/main/Sources/CLI/BuildCommand.swift#L84
• https://github.com/apple/container/blob/main/Sources/CLI/Image/ImageLoad.swift#L37

[jglogan]

Also asking about possibilities over at: https://forums.swift.org/t/using-an-optiongroup-and-invoking-a-parseablecommand-as-a-client-of-a-cli-library/82158

[Mcrich23]

Sounds good. One option is to create an enum of properties and a parameter for the properties to omit from the output. Then it gets passed onto the dev to use correctly and bypasses this issue?

[Mcrich23]

Also asking about possibilities over at: https://forums.swift.org/t/using-an-optiongroup-and-invoking-a-parseablecommand-as-a-client-of-a-cli-library/82158

@jglogan Any updates on this? Should I develop a member macro to do this? I think it would be great to solve this issue ahead of publishing documentation around Plugins

[katiewasnothere]

@Mcrich23 I don't love the idea of calling a CLI command from another CLI command, similar to what @jglogan mentioned. ContainerCreate may modify the arguments provided to it and there's no way for the caller to get the resulting values (as of now) and I can't think of a clean way to do this either. I would rather we setup reasonable code sharing or enable hooks that allow people to extend calls like ContainerCreate without needing to reimplement the whole thing. Just some ideas to think about, but I'm open to other thoughts here for sure.

[Mcrich23]

I understand what you are saying. I think those are cases where we could consider making those properties public for plugins to access. Initially, I had proposed the idea of plugins having full access to properties of commands to make extensive capabilities. Ultimately, we moved forward with just exposing the parse, validate, and run functions for CLI commands. If this decision has changed, I would be happy to open a PR making those properties public instead.

If we do decide to keep the current CLI command calling design choice for now, I believe that a macro must also exist for good UX. Container-Compose has been sitting on my fork with the macro for a long time because I wanted to provide easy flag support for commands without having to hardcode each individual flag. A macro makes this easy to maintain as it requires zero line changes from anyone, just recompilation.

If we want to switch to CLI Command initialization instead of parse and run, I fully support that and would be happy to make that into a PR. It would also solve this issue.

[Mcrich23]

@jglogan @katiewasnothere I really would like to figure out a solution regarding this. If it is something that might be better suited to figure out over the phone, I think we are connected on LinkedIn and I would be happy to chat there or on twitter.