Support CLI integration of ostree-rs-ext

[cgwalters]

Basically what I think we should support is something like:
/usr/lib/ostree/ostree-ext
which if detected, /usr/bin/ostree automatically gains support for e.g. ostree ex-container mapping to ostree-ext container.

(Right now for rpm-ostree we are vendoring the library, so most likely we'd make it so /usr/lib/ostree/ostree-ext was a hardlink to /usr/bin/rpm-ostree, and then auto-detect via argv[0] that we should behave as ostree-ext)

In general this path leads to a more seamless UX.

[lucab]

I agree this would be nice to have. Bunch of questions to push this forward:

• How do you feel about dedicating a binary name or CLI verb to this extension mechanism (ostree-extra or ostree extra)? That way I think we can directly map a subverb to an extension binary, without clashes.
• What's the expected arrangement for rpm-ostree and ostree-rs-ext binaries? Given that they do provide basically the same verbs, did you intend them to be mutually exclusive for installation?

[cgwalters]

How do you feel about dedicating a binary name or CLI verb to this extension mechanism (ostree-extra or ostree extra)? That way I think we can directly map a subverb to an extension binary, without clashes.

I like the git (and cargo) approach of "if git/cargo $foo is not recognized, look for git-$foo instead".

That said, it's not clear to me that ostree needs this level of external extensibility, versus hardcoding support for ostree-ext.

What's the expected arrangement for rpm-ostree and ostree-rs-ext binaries? Given that they do provide basically the same verbs, did you intend them to be mutually exclusive for installation?

We should definitely support people using ostree-ext independently of rpm-ostree. But...the thing is, dealing with Rust and vendoring and crate dependencies etc., it seems by far simpler to me to have rpm-ostree vendor ostree-ext instead of shipping it independently, at least in Fedora.

This is what I was getting at with the above:

(Right now for rpm-ostree we are vendoring the library, so most likely we'd make it so /usr/lib/ostree/ostree-ext was a hardlink to /usr/bin/rpm-ostree, and then auto-detect via argv[0] that we should behave as ostree-ext)

[lucab]

Yes, I'd be happy with that lookup logic too (assuming it's sanely feasible).
Both git and cargo do lookup for binaries in PATH, I'm not sure if you were actually looking for that feature too, or only restrict to a well-know directory under lib?

Also, from an out-of-band chat, we figured out we are fine with making rpm-ostree and ostree-rs-ext CLI binaries mutually exclusive (i.e. not co-installable).

[cgwalters]

Perhaps one simple way to approach this is to "reserve" names on the ostree-c side. For example, take the current set of sub-verbs of ostree-rs-ext:

$ ostree-ext-cli --help
...
SUBCOMMANDS:
    container    Import and export to a container image
    help         Prints this message or the help of the given subcommand(s)
    ima-sign     IMA signatures
    tar          Import and export to tar

We'd add stubs into main.c here that detect $verb and call /usr/lib/ostree-ext $verb.

The rpm-ostree multicall stuff could actually then just take over /usr/bin/ostree entirely too. So the user experience would be typing ostree container, and we wouldn't actually need to have rpm-ostree ex-container at all.

WDYT?

[cgwalters]

Oh sorry, you said basically the same thing in coreos/rpm-ostree#3281 (comment) I think

[lucab]

So the user experience would be typing ostree container, and we wouldn't actually need to have rpm-ostree ex-container at all.

Yes, this is exactly my understanding of the plan.

Perhaps one simple way to approach this is to "reserve" names on the ostree-c side.
We'd add stubs into main.c here that detect $verb and call /usr/lib/ostree-ext $verb.

We can put in place this allowlist if we prefer, but strictly speaking we don't need to.
To push the discussion forward I opened #2500 with logic directly inspired from cargo:

• extract the extcommand verb from a call like ostree extcommand --help
• check whether it is a known internal command, continue as usual if so
• otherwise, try to lookup an ostree-extcommand binary in $PATH
• if found, dispatch further execution to ostree-extcommand extcommand --help
• otherwise, fallback to usual ostree CLI error handling

If we land coreos/rpm-ostree#3281 and place an hardlink rpm-ostree -> ostree-container, then final UX here would be ostree container --help going to the rpm-ostree multicall case-switch for ostree-container.