Allow plugins to report their own version and store it in the registry

[devyn]

Description

This allows plugins to report their version (and potentially other metadata in the future). The version is shown in plugin list and in version.

The metadata is stored in the registry file, and reflects whatever was retrieved on plugin add, not necessarily the running binary. This can help you to diagnose if there's some kind of mismatch with what you expect. We could potentially use this functionality to show a warning or error if a plugin being run does not have the same version as what was in the cache file, suggesting plugin add be run again, but I haven't done that at this point.

It is optional, and it requires the plugin author to make some code changes if they want to provide it, since I can't automatically determine the version of the calling crate or anything tricky like that to do it.

Example:

> plugin list | select name version is_running pid
╭───┬────────────────┬─────────┬────────────┬─────╮
│ # │      name      │ version │ is_running │ pid │
├───┼────────────────┼─────────┼────────────┼─────┤
│ 0 │ example        │ 0.93.1  │ false      │     │
│ 1 │ gstat          │ 0.93.1  │ false      │     │
│ 2 │ inc            │ 0.93.1  │ false      │     │
│ 3 │ python_example │ 0.1.0   │ false      │     │
╰───┴────────────────┴─────────┴────────────┴─────╯

cc @maxim-uvarov (he asked for it)

User-Facing Changes

• plugin list gets a version column
• version shows plugin versions when available
• plugin authors must add fn version() to their impl Plugin

Tests + Formatting

Tested the low level stuff and also the plugin list column.

After Submitting

• update plugin guide docs
• update plugin protocol docs (Metadata call & response)
• update plugin template (fn version() should be easy)
• release notes

[fdncred]

I think it's a great idea to have plugin metadata for version and other potential stuff but I'm on the fence about making it optional. If someone wants to rely on it and it's optional, it makes it not as helpful because people can opt-out.

[devyn]

I can design the rust API to make it required then, e.g. with a fn version() For others it should be obvious because they'll have to implement Metadata.

[fdncred]

I could be wrong, but I think that sounds better.

[devyn]

I think this does that, then. The fn version(&self) -> String is required to be implemented in Rust, but it's technically an optional field still as far as the protocol goes.

[devyn]

@fdncred I'm up for giving this a try for this release if you don't mind. It's nothing big and scary but does create a small breaking change for plugin developers.

[fdncred]

ok, here's to breaking everyone's plugins again. 🍺

[fdncred]

After changing a bunch of plugins, shouldn't this just default to

    fn version(&self) -> String {
        env!("CARGO_PKG_VERSION").into()
    }

and not be a breaking change. If people want a different version, they could override it.

[devyn]

After changing a bunch of plugins, shouldn't this just default to

    fn version(&self) -> String {
        env!("CARGO_PKG_VERSION").into()
    }

and not be a breaking change. If people want a different version, they could override it.

I wish we could, but the env! macro is local to the crate that's compiling it, so a default implementation would pick up the version of nu-plugin-core rather than the plugin version. 😢

[fdncred]

boo!