2022-07-25 18:32:56 +02:00
|
|
|
mod cool_custom_value;
|
|
|
|
mod second_custom_value;
|
|
|
|
|
|
|
|
use cool_custom_value::CoolCustomValue;
|
2022-08-21 13:13:38 +02:00
|
|
|
use nu_plugin::{serve_plugin, MsgPackSerializer, Plugin};
|
2022-07-25 18:32:56 +02:00
|
|
|
use nu_plugin::{EvaluatedCall, LabeledError};
|
Make plugin commands support examples. (#7984)
# Description
As title, we can't provide examples for plugin commands, this pr would
make it possible
# User-Facing Changes
Take plugin `nu-example-1` as example:
```
❯ nu-example-1 -h
PluginSignature test 1 for plugin. Returns Value::Nothing
Usage:
> nu-example-1 {flags} <a> <b> (opt) ...(rest)
Flags:
-h, --help - Display the help message for this command
-f, --flag - a flag for the signature
-n, --named <String> - named string
Parameters:
a <int>: required integer value
b <string>: required string value
(optional) opt <int>: Optional number
...rest <string>: rest value string
Examples:
running example with an int value and string value
> nu-example-1 3 bb
```
The examples session is newly added.
## Basic idea behind these changes
when nushell query plugin signatures, plugin just returns it's signature
without any examples, so nushell have no idea about the examples of
plugin commands.
To adding the feature, we just making plugin returns it's signature with
examples.
Before:
```
1. get signature
---------------->
Nushell ------------------ Plugin
<-----------------
2. returns Vec<Signature>
```
After:
```
1. get signature
---------------->
Nushell ------------------ Plugin
<-----------------
2. returns Vec<PluginSignature>
```
When writing plugin signature to $nu.plugin-path:
Serialize `<PluginSignature>` rather than `<Signature>`, which would
enable us to serialize examples to `$nu.plugin-path`
## Shortcoming
It's a breaking changes because `Plugin::signature` is changed, and it
requires plugin authors to change their code for new signatures.
Fortunally it should be easy to change, for rust based plugin, we just
need to make a global replace from word `Signature` to word
`PluginSignature` in their plugin project.
Our content of plugin-path is really large, if one plugin have many
examples, it'd results to larger body of $nu.plugin-path, which is not
really scale. A solution would be save register information in other
binary formats rather than `json`. But I think it'd be another story.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2023-02-08 23:14:18 +01:00
|
|
|
use nu_protocol::{Category, PluginSignature, ShellError, Value};
|
2022-07-25 18:32:56 +02:00
|
|
|
use second_custom_value::SecondCustomValue;
|
|
|
|
|
|
|
|
struct CustomValuePlugin;
|
|
|
|
|
|
|
|
impl Plugin for CustomValuePlugin {
|
Make plugin commands support examples. (#7984)
# Description
As title, we can't provide examples for plugin commands, this pr would
make it possible
# User-Facing Changes
Take plugin `nu-example-1` as example:
```
❯ nu-example-1 -h
PluginSignature test 1 for plugin. Returns Value::Nothing
Usage:
> nu-example-1 {flags} <a> <b> (opt) ...(rest)
Flags:
-h, --help - Display the help message for this command
-f, --flag - a flag for the signature
-n, --named <String> - named string
Parameters:
a <int>: required integer value
b <string>: required string value
(optional) opt <int>: Optional number
...rest <string>: rest value string
Examples:
running example with an int value and string value
> nu-example-1 3 bb
```
The examples session is newly added.
## Basic idea behind these changes
when nushell query plugin signatures, plugin just returns it's signature
without any examples, so nushell have no idea about the examples of
plugin commands.
To adding the feature, we just making plugin returns it's signature with
examples.
Before:
```
1. get signature
---------------->
Nushell ------------------ Plugin
<-----------------
2. returns Vec<Signature>
```
After:
```
1. get signature
---------------->
Nushell ------------------ Plugin
<-----------------
2. returns Vec<PluginSignature>
```
When writing plugin signature to $nu.plugin-path:
Serialize `<PluginSignature>` rather than `<Signature>`, which would
enable us to serialize examples to `$nu.plugin-path`
## Shortcoming
It's a breaking changes because `Plugin::signature` is changed, and it
requires plugin authors to change their code for new signatures.
Fortunally it should be easy to change, for rust based plugin, we just
need to make a global replace from word `Signature` to word
`PluginSignature` in their plugin project.
Our content of plugin-path is really large, if one plugin have many
examples, it'd results to larger body of $nu.plugin-path, which is not
really scale. A solution would be save register information in other
binary formats rather than `json`. But I think it'd be another story.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2023-02-08 23:14:18 +01:00
|
|
|
fn signature(&self) -> Vec<nu_protocol::PluginSignature> {
|
2022-07-25 18:32:56 +02:00
|
|
|
vec after the
PR is merged, if necessary. This will help us keep the docs up to date.
2023-02-08 23:14:18 +01:00
|
|
|
PluginSignature::build("custom-value generate")
|
|
|
|
.usage("PluginSignature for a plugin that generates a custom value")
|
2022-07-25 18:32:56 +02:00
|
|
|
.category(Category::Experimental),
|
Make plugin commands support examples. (#7984)
# Description
As title, we can't provide examples for plugin commands, this pr would
make it possible
# User-Facing Changes
Take plugin `nu-example-1` as example:
```
❯ nu-example-1 -h
PluginSignature test 1 for plugin. Returns Value::Nothing
Usage:
> nu-example-1 {flags} <a> <b> (opt) ...(rest)
Flags:
-h, --help - Display the help message for this command
-f, --flag - a flag for the signature
-n, --named <String> - named string
Parameters:
a <int>: required integer value
b <string>: required string value
(optional) opt <int>: Optional number
...rest <string>: rest value string
Examples:
running example with an int value and string value
> nu-example-1 3 bb
```
The examples session is newly added.
## Basic idea behind these changes
when nushell query plugin signatures, plugin just returns it's signature
without any examples, so nushell have no idea about the examples of
plugin commands.
To adding the feature, we just making plugin returns it's signature with
examples.
Before:
```
1. get signature
---------------->
Nushell ------------------ Plugin
<-----------------
2. returns Vec<Signature>
```
After:
```
1. get signature
---------------->
Nushell ------------------ Plugin
<-----------------
2. returns Vec<PluginSignature>
```
When writing plugin signature to $nu.plugin-path:
Serialize `<PluginSignature>` rather than `<Signature>`, which would
enable us to serialize examples to `$nu.plugin-path`
## Shortcoming
It's a breaking changes because `Plugin::signature` is changed, and it
requires plugin authors to change their code for new signatures.
Fortunally it should be easy to change, for rust based plugin, we just
need to make a global replace from word `Signature` to word
`PluginSignature` in their plugin project.
Our content of plugin-path is really large, if one plugin have many
examples, it'd results to larger body of $nu.plugin-path, which is not
really scale. A solution would be save register information in other
binary formats rather than `json`. But I think it'd be another story.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2023-02-08 23:14:18 +01:00
|
|
|
PluginSignature::build("custom-value generate2")
|
|
|
|
.usage("PluginSignature for a plugin that generates a different custom value")
|
2022-07-25 18:32:56 +02:00
|
|
|
.category(Category::Experimental),
|
Make plugin commands support examples. (#7984)
# Description
As title, we can't provide examples for plugin commands, this pr would
make it possible
# User-Facing Changes
Take plugin `nu-example-1` as example:
```
❯ nu-example-1 -h
PluginSignature test 1 for plugin. Returns Value::Nothing
Usage:
> nu-example-1 {flags} <a> <b> (opt) ...(rest)
Flags:
-h, --help - Display the help message for this command
-f, --flag - a flag for the signature
-n, --named <String> - named string
Parameters:
a <int>: required integer value
b <string>: required string value
(optional) opt <int>: Optional number
...rest <string>: rest value string
Examples:
running example with an int value and string value
> nu-example-1 3 bb
```
The examples session is newly added.
## Basic idea behind these changes
when nushell query plugin signatures, plugin just returns it's signature
without any examples, so nushell have no idea about the examples of
plugin commands.
To adding the feature, we just making plugin returns it's signature with
examples.
Before:
```
1. get signature
---------------->
Nushell ------------------ Plugin
<-----------------
2. returns Vec<Signature>
```
After:
```
1. get signature
---------------->
Nushell ------------------ Plugin
<-----------------
2. returns Vec<PluginSignature>
```
When writing plugin signature to $nu.plugin-path:
Serialize `<PluginSignature>` rather than `<Signature>`, which would
enable us to serialize examples to `$nu.plugin-path`
## Shortcoming
It's a breaking changes because `Plugin::signature` is changed, and it
requires plugin authors to change their code for new signatures.
Fortunally it should be easy to change, for rust based plugin, we just
need to make a global replace from word `Signature` to word
`PluginSignature` in their plugin project.
Our content of plugin-path is really large, if one plugin have many
examples, it'd results to larger body of $nu.plugin-path, which is not
really scale. A solution would be save register information in other
binary formats rather than `json`. But I think it'd be another story.
# Tests + Formatting
Don't forget to add tests that cover your changes.
Make sure you've run and fixed any issues with these commands:
- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
# After Submitting
If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
2023-02-08 23:14:18 +01:00
|
|
|
PluginSignature::build("custom-value update")
|
|
|
|
.usage("PluginSignature for a plugin that updates a custom value")
|
2022-07-25 18:32:56 +02:00
|
|
|
.category(Category::Experimental),
|
|
|
|
]
|
|
|
|
}
|
|
|
|
|
|
|
|
fn run(
|
|
|
|
&mut self,
|
|
|
|
name: &str,
|
|
|
|
call: &EvaluatedCall,
|
|
|
|
input: &Value,
|
|
|
|
) -> Result<Value, LabeledError> {
|
|
|
|
match name {
|
|
|
|
"custom-value generate" => self.generate(call, input),
|
|
|
|
"custom-value generate2" => self.generate2(call, input),
|
|
|
|
"custom-value update" => self.update(call, input),
|
|
|
|
_ => Err(LabeledError {
|
|
|
|
label: "Plugin call with wrong name signature".into(),
|
|
|
|
msg: "the signature used to call the plugin does not match any name in the plugin signature vector".into(),
|
|
|
|
span: Some(call.head),
|
|
|
|
}),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl CustomValuePlugin {
|
|
|
|
fn generate(&mut self, call: &EvaluatedCall, _input: &Value) -> Result<Value, LabeledError> {
|
|
|
|
Ok(CoolCustomValue::new("abc").into_value(call.head))
|
|
|
|
}
|
|
|
|
|
|
|
|
fn generate2(&mut self, call: &EvaluatedCall, _input: &Value) -> Result<Value, LabeledError> {
|
|
|
|
Ok(SecondCustomValue::new("xyz").into_value(call.head))
|
|
|
|
}
|
|
|
|
|
|
|
|
fn update(&mut self, call: &EvaluatedCall, input: &Value) -> Result<Value, LabeledError> {
|
|
|
|
if let Ok(mut value) = CoolCustomValue::try_from_value(input) {
|
|
|
|
value.cool += "xyz";
|
|
|
|
return Ok(value.into_value(call.head));
|
|
|
|
}
|
|
|
|
|
|
|
|
if let Ok(mut value) = SecondCustomValue::try_from_value(input) {
|
|
|
|
value.something += "abc";
|
|
|
|
return Ok(value.into_value(call.head));
|
|
|
|
}
|
|
|
|
|
2023-03-06 18:33:09 +01:00
|
|
|
Err(ShellError::CantConvert {
|
|
|
|
to_type: "cool or second".into(),
|
|
|
|
from_type: "non-cool and non-second".into(),
|
|
|
|
span: call.head,
|
|
|
|
help: None,
|
|
|
|
}
|
2022-07-25 18:32:56 +02:00
|
|
|
.into())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn main() {
|
2022-08-21 13:13:38 +02:00
|
|
|
serve_plugin(&mut CustomValuePlugin, MsgPackSerializer {})
|
2022-07-25 18:32:56 +02:00
|
|
|
}
|