nushell/crates/nu-plugin-protocol/Cargo.toml

[package]
authors = ["The Nushell Project Developers"]
description = "Protocol type definitions for Nushell plugins"
repository = "https://github.com/nushell/nushell/tree/main/crates/nu-plugin-protocol"
edition = "2021"
license = "MIT"
name = "nu-plugin-protocol"
version = "0.93.0"

[lib]
bench = false

[dependencies]
nu-protocol = { path = "../nu-protocol", version = "0.93.0", features = ["plugin"] }
nu-utils = { path = "../nu-utils", version = "0.93.0" }

bincode = "1.3"
serde = { workspace = true, features = ["derive"] }
semver = "1.0"
typetag = "0.2"

[features]
default = ["local-socket"]
local-socket = []
Split the plugin crate (#12563) # Description This breaks `nu-plugin` up into four crates: - `nu-plugin-protocol`: just the type definitions for the protocol, no I/O. If someone wanted to wire up something more bare metal, maybe for async I/O, they could use this. - `nu-plugin-core`: the shared stuff between engine/plugin. Less stable interface. - `nu-plugin-engine`: everything required for the engine to talk to plugins. Less stable interface. - `nu-plugin`: everything required for the plugin to talk to the engine, what plugin developers use. Should be the most stable interface. No changes are made to the interface exposed by `nu-plugin` - it should all still be there. Re-exports from `nu-plugin-protocol` or `nu-plugin-core` are used as required. Plugins shouldn't ever have to use those crates directly. This should be somewhat faster to compile as `nu-plugin-engine` and `nu-plugin` can compile in parallel, and the engine doesn't need `nu-plugin` and plugins don't need `nu-plugin-engine` (except for test support), so that should reduce what needs to be compiled too. The only significant change here other than splitting stuff up was to break the `source` out of `PluginCustomValue` and create a new `PluginCustomValueWithSource` type that contains that instead. One bonus of that is we get rid of the option and it's now more type-safe, but it also means that the logic for that stuff (actually running the plugin for custom value ops) can live entirely within the `nu-plugin-engine` crate. # User-Facing Changes - New crates. - Added `local-socket` feature for `nu` to try to make it possible to compile without that support if needed. # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` 2024-04-27 19:08:12 +02:00			`[package]`
			`authors = ["The Nushell Project Developers"]`
			`description = "Protocol type definitions for Nushell plugins"`
			`repository = "https://github.com/nushell/nushell/tree/main/crates/nu-plugin-protocol"`
			`edition = "2021"`
			`license = "MIT"`
			`name = "nu-plugin-protocol"`
Bump version to `0.93.0` (#12709) # Description Bump version to `0.93.0` 2024-05-01 00:51:13 +02:00			`version = "0.93.0"`
Split the plugin crate (#12563) # Description This breaks `nu-plugin` up into four crates: - `nu-plugin-protocol`: just the type definitions for the protocol, no I/O. If someone wanted to wire up something more bare metal, maybe for async I/O, they could use this. - `nu-plugin-core`: the shared stuff between engine/plugin. Less stable interface. - `nu-plugin-engine`: everything required for the engine to talk to plugins. Less stable interface. - `nu-plugin`: everything required for the plugin to talk to the engine, what plugin developers use. Should be the most stable interface. No changes are made to the interface exposed by `nu-plugin` - it should all still be there. Re-exports from `nu-plugin-protocol` or `nu-plugin-core` are used as required. Plugins shouldn't ever have to use those crates directly. This should be somewhat faster to compile as `nu-plugin-engine` and `nu-plugin` can compile in parallel, and the engine doesn't need `nu-plugin` and plugins don't need `nu-plugin-engine` (except for test support), so that should reduce what needs to be compiled too. The only significant change here other than splitting stuff up was to break the `source` out of `PluginCustomValue` and create a new `PluginCustomValueWithSource` type that contains that instead. One bonus of that is we get rid of the option and it's now more type-safe, but it also means that the logic for that stuff (actually running the plugin for custom value ops) can live entirely within the `nu-plugin-engine` crate. # User-Facing Changes - New crates. - Added `local-socket` feature for `nu` to try to make it possible to compile without that support if needed. # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` 2024-04-27 19:08:12 +02:00
			`[lib]`
			`bench = false`

			`[dependencies]`
Bump version to `0.93.0` (#12709) # Description Bump version to `0.93.0` 2024-05-01 00:51:13 +02:00			`nu-protocol = { path = "../nu-protocol", version = "0.93.0", features = ["plugin"] }`
			`nu-utils = { path = "../nu-utils", version = "0.93.0" }`
Split the plugin crate (#12563) # Description This breaks `nu-plugin` up into four crates: - `nu-plugin-protocol`: just the type definitions for the protocol, no I/O. If someone wanted to wire up something more bare metal, maybe for async I/O, they could use this. - `nu-plugin-core`: the shared stuff between engine/plugin. Less stable interface. - `nu-plugin-engine`: everything required for the engine to talk to plugins. Less stable interface. - `nu-plugin`: everything required for the plugin to talk to the engine, what plugin developers use. Should be the most stable interface. No changes are made to the interface exposed by `nu-plugin` - it should all still be there. Re-exports from `nu-plugin-protocol` or `nu-plugin-core` are used as required. Plugins shouldn't ever have to use those crates directly. This should be somewhat faster to compile as `nu-plugin-engine` and `nu-plugin` can compile in parallel, and the engine doesn't need `nu-plugin` and plugins don't need `nu-plugin-engine` (except for test support), so that should reduce what needs to be compiled too. The only significant change here other than splitting stuff up was to break the `source` out of `PluginCustomValue` and create a new `PluginCustomValueWithSource` type that contains that instead. One bonus of that is we get rid of the option and it's now more type-safe, but it also means that the logic for that stuff (actually running the plugin for custom value ops) can live entirely within the `nu-plugin-engine` crate. # User-Facing Changes - New crates. - Added `local-socket` feature for `nu` to try to make it possible to compile without that support if needed. # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` 2024-04-27 19:08:12 +02:00
			`bincode = "1.3"`
			`serde = { workspace = true, features = ["derive"] }`
			`semver = "1.0"`
			`typetag = "0.2"`
Fix missing local socket feature (#12698) # Description So sorry to do this during the pre-release freeze, but my plugin crate split PR broke local socket mode, because `nu-plugin-protocol` didn't have the compile feature to advertise the `LocalSocket` protocol feature. This is a very simple, configuration-only bugfix that I think really needs to be merged before the release, or else local socket mode won't work at all. # Tests + Formatting There's an oversight in my testing that caused this to not be caught: the engine really did have the feature, but it just wasn't advertising it, so for `stress_internals` it was still able to use it successfully. Post-release I'll try to make sure this is properly handled somehow. 2024-04-29 09:02:56 +02:00
			`[features]`
			`default = ["local-socket"]`
			`local-socket = []`