mirror of
https://github.com/nushell/nushell.git
synced 2024-11-28 19:33:47 +01:00
01d30a416b
# Description
This is something that was discussed in the core team meeting last
Wednesday. @ayax79 is building `nu-plugin-polars` with all of the
dataframe commands into a plugin, and there are a lot of them, so it
would help to make the API more similar. At the same time, I think the
`Command` API is just better anyway. I don't think the difference is
justified, and the types for core commands have the benefit of requiring
less `.into()` because they often don't own their data
- Broke `signature()` up into `name()`, `usage()`, `extra_usage()`,
`search_terms()`, `examples()`
- `signature()` returns `nu_protocol::Signature`
- `examples()` returns `Vec<nu_protocol::Example>`
- `PluginSignature` and `PluginExample` no longer need to be used by
plugin developers
# User-Facing Changes
Breaking API for plugins yet again 😄
31 lines
1.6 KiB
Rust
31 lines
1.6 KiB
Rust
use nu_plugin::{serve_plugin, MsgPackSerializer};
|
|
use nu_plugin_example::ExamplePlugin;
|
|
|
|
fn main() {
|
|
// When defining your plugin, you can select the Serializer that could be
|
|
// used to encode and decode the messages. The available options are
|
|
// MsgPackSerializer and JsonSerializer. Both are defined in the serializer
|
|
// folder in nu-plugin.
|
|
serve_plugin(&ExamplePlugin {}, MsgPackSerializer {})
|
|
|
|
// Note
|
|
// When creating plugins in other languages one needs to consider how a plugin
|
|
// is added and used in nushell.
|
|
// The steps are:
|
|
// - The plugin is register. In this stage nushell calls the binary file of
|
|
// the plugin sending information using the encoded PluginCall::PluginSignature object.
|
|
// Use this encoded data in your plugin to design the logic that will return
|
|
// the encoded signatures.
|
|
// Nushell is expecting and encoded PluginResponse::PluginSignature with all the
|
|
// plugin signatures
|
|
// - When calling the plugin, nushell sends to the binary file the encoded
|
|
// PluginCall::CallInfo which has all the call information, such as the
|
|
// values of the arguments, the name of the signature called and the input
|
|
// from the pipeline.
|
|
// Use this data to design your plugin login and to create the value that
|
|
// will be sent to nushell
|
|
// Nushell expects an encoded PluginResponse::Value from the plugin
|
|
// - If an error needs to be sent back to nushell, one can encode PluginResponse::Error.
|
|
// This is a labeled error that nushell can format for pretty printing
|
|
}
|