extern/nushell
1
0
Fork 1
mirror of https://github.com/nushell/nushell.git synced 2024-11-08 09:34:30 +01:00
Code Issues Packages Projects Releases Wiki Activity
8e763a2fd6
nushell/crates/nu-plugin/Cargo.toml

32 lines
774 B
TOML
Raw Normal View History

Nu plugins now depend on nu-plugin crate.
2019-12-27 14:30:14 +01:00
[package]
Add licenses (#4893) * Add licenses * Add licenses
2022-03-22 21:25:38 +01:00
authors = ["The Nushell Project Developers"]
Update incorrect crate descriptions (#5159)
2022-04-11 20:17:06 +02:00
description = "Functionality for building Nushell plugins"
Add repository info to all workspace crates (#6320) This helps people who find these crates on crates.io
2022-08-14 14:21:20 +02:00
repository = "https://github.com/nushell/nushell/tree/main/crates/nu-plugin"
Add licenses (#4893) * Add licenses * Add licenses
2022-03-22 21:25:38 +01:00
edition = "2021"
license = "MIT"
Bump to 0.16.1 (#2116)
2020-07-05 22:12:44 +02:00
name = "nu-plugin"
Bump version to `0.91.1` (#12085)
2024-03-06 23:08:14 +01:00
version = "0.91.1"
plugin command
2021-10-23 22:08:54 +02:00
Disable auto-benchmark harness for crates (#8057) # Description This disables automatic detection of `#[bench]` and other benchmarks within the crates. Our benchmarks should all live in `benches` This fixes a problem with criterion flags and should also reduce the build requirements for `cargo bench` a bit Taken from https://github.com/nushell/nushell/pull/7952 See: https://bheisler.github.io/criterion.rs/book/faq.html#cargo-bench-gives-unrecognized-option-errors-for-valid-command-line-options # User-Facing Changes None
2023-02-12 23:22:00 +01:00
[lib]
bench = false
plugin command
2021-10-23 22:08:54 +02:00
[dependencies]
Bump version to `0.91.1` (#12085)
2024-03-06 23:08:14 +01:00
nu-engine = { path = "../nu-engine", version = "0.91.1" }
nu-protocol = { path = "../nu-protocol", version = "0.91.1" }
remove unused dependencies (#9230) # Description This is a test PR to see if we can remove dependencies. The crates to remove was generated from cargo machete. If ci works, I'll update the PR to remove deps instead of comment them out. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # 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-05-18 18:37:20 +02:00
update most dependencies except where deeper code changes are needed (#9296) # Description This PR updates most dependencies and tries to get in sync with reedline. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> # 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 -A clippy::result_large_err` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass - `cargo run -- crates/nu-std/tests/run.nu` to run the tests for the standard library > **Note** > from `nushell` you can also use the `toolkit` as follows > ```bash > use toolkit.nu # or use an `env_change` hook to activate it automatically > toolkit check pr > ``` --> # 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-05-26 17:32:48 +02:00
bincode = "1.3"
rmp-serde = "1.1"
Move more dependencies to workspace level (#12270) # Description This is a followup to #12043 that moves more dependency versions to workspace dependencies. # User-Facing Changes N/A # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib`
2024-03-24 00:46:02 +01:00
serde = { workspace = true }
Introduce workspace dependencies (#12043) # Description This PR introduces [workspaces dependencies](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-dependencies-table). The advantages are: - a single place where dependency versions are declared - reduces the number of files to change when upgrading a dependency - reduces the risk of accidentally depending on 2 different versions of the same dependency I've only done a few so far. If this PR is accepted, I might continue and progressively do the rest. # User-Facing Changes N/A # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting N/A
2024-03-07 23:40:31 +01:00
serde_json = { workspace = true }
Bidirectional communication and streams for plugins (#11911)
2024-02-25 23:32:50 +01:00
log = "0.4"
Introduce workspace dependencies (#12043) # Description This PR introduces [workspaces dependencies](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-dependencies-table). The advantages are: - a single place where dependency versions are declared - reduces the number of files to change when upgrading a dependency - reduces the risk of accidentally depending on 2 different versions of the same dependency I've only done a few so far. If this PR is accepted, I might continue and progressively do the rest. # User-Facing Changes N/A # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting N/A
2024-03-07 23:40:31 +01:00
miette = { workspace = true }
Bidirectional communication and streams for plugins (#11911)
2024-02-25 23:32:50 +01:00
semver = "1.0"
typetag = "0.2"
Add test support crate for plugin developers (#12259) # Description Adds a `nu-plugin-test-support` crate with an interface that supports testing plugins. Unlike in reality, these plugins run in the same process on separate threads. This will allow testing aspects of the plugin internal state and handling serialized plugin custom values easily. We still serialize their custom values and all of the engine to plugin logic is still in play, so from a logical perspective this should still expose any bugs that would have been caused by that. The only difference is that it doesn't run in a different process, and doesn't try to serialize everything to the final wire format for stdin/stdout. TODO still: - [x] Clean up warnings about private types exposed in trait definition - [x] Automatically deserialize plugin custom values in the result so they can be inspected - [x] Automatic plugin examples test function - [x] Write a bit more documentation - [x] More tests - [x] Add MIT License file to new crate # User-Facing Changes Plugin developers get a nice way to test their plugins. # Tests + Formatting Run the tests with `cargo test -p nu-plugin-test-support -- --show-output` to see some examples of what the failing test output for examples can look like. I used the `difference` crate (MIT licensed) to make it look nice. - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting - [ ] Add a section to the book about testing - [ ] Test some of the example plugins this way - [ ] Add example tests to nu_plugin_template so plugin developers have something to start with
2024-03-23 19:29:54 +01:00
thiserror = "1.0"
Keep plugins persistently running in the background (#12064) # Description This PR uses the new plugin protocol to intelligently keep plugin processes running in the background for further plugin calls. Running plugins can be seen by running the new `plugin list` command, and stopped by running the new `plugin stop` command. This is an enhancement for the performance of plugins, as starting new plugin processes has overhead, especially for plugins in languages that take a significant amount of time on startup. It also enables plugins that have persistent state between commands, making the migration of features like dataframes and `stor` to plugins possible. Plugins are automatically stopped by the new plugin garbage collector, configurable with `$env.config.plugin_gc`: ```nushell $env.config.plugin_gc = { # Configuration for plugin garbage collection default: { enabled: true # true to enable stopping of inactive plugins stop_after: 10sec # how long to wait after a plugin is inactive to stop it } plugins: { # alternate configuration for specific plugins, by name, for example: # # gstat: { # enabled: false # } } } ``` If garbage collection is enabled, plugins will be stopped after `stop_after` passes after they were last active. Plugins are counted as inactive if they have no running plugin calls. Reading the stream from the response of a plugin call is still considered to be activity, but if a plugin holds on to a stream but the call ends without an active streaming response, it is not counted as active even if it is reading it. Plugins can explicitly disable the GC as appropriate with `engine.set_gc_disabled(true)`. The `version` command now lists plugin names rather than plugin commands. The list of plugin commands is accessible via `plugin list`. Recommend doing this together with #12029, because it will likely force plugin developers to do the right thing with mutability and lead to less unexpected behavior when running plugins nested / in parallel. # User-Facing Changes - new command: `plugin list` - new command: `plugin stop` - changed command: `version` (now lists plugin names, rather than commands) - new config: `$env.config.plugin_gc` - Plugins will keep running and be reused, at least for the configured GC period - Plugins that used mutable state in weird ways like `inc` did might misbehave until fixed - Plugins can disable GC if they need to - Had to change plugin signature to accept `&EngineInterface` so that the GC disable feature works. #12029 does this anyway, and I'm expecting (resolvable) conflicts with that # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` Because there is some specific OS behavior required for plugins to not respond to Ctrl-C directly, I've developed against and tested on both Linux and Windows to ensure that works properly. # After Submitting I think this probably needs to be in the book somewhere
2024-03-10 00:10:22 +01:00
[target.'cfg(target_os = "windows")'.dependencies]
Move more dependencies to workspace level (#12270) # Description This is a followup to #12043 that moves more dependency versions to workspace dependencies. # User-Facing Changes N/A # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib`
2024-03-24 00:46:02 +01:00
windows = { workspace = true, features = [
Keep plugins persistently running in the background (#12064) # Description This PR uses the new plugin protocol to intelligently keep plugin processes running in the background for further plugin calls. Running plugins can be seen by running the new `plugin list` command, and stopped by running the new `plugin stop` command. This is an enhancement for the performance of plugins, as starting new plugin processes has overhead, especially for plugins in languages that take a significant amount of time on startup. It also enables plugins that have persistent state between commands, making the migration of features like dataframes and `stor` to plugins possible. Plugins are automatically stopped by the new plugin garbage collector, configurable with `$env.config.plugin_gc`: ```nushell $env.config.plugin_gc = { # Configuration for plugin garbage collection default: { enabled: true # true to enable stopping of inactive plugins stop_after: 10sec # how long to wait after a plugin is inactive to stop it } plugins: { # alternate configuration for specific plugins, by name, for example: # # gstat: { # enabled: false # } } } ``` If garbage collection is enabled, plugins will be stopped after `stop_after` passes after they were last active. Plugins are counted as inactive if they have no running plugin calls. Reading the stream from the response of a plugin call is still considered to be activity, but if a plugin holds on to a stream but the call ends without an active streaming response, it is not counted as active even if it is reading it. Plugins can explicitly disable the GC as appropriate with `engine.set_gc_disabled(true)`. The `version` command now lists plugin names rather than plugin commands. The list of plugin commands is accessible via `plugin list`. Recommend doing this together with #12029, because it will likely force plugin developers to do the right thing with mutability and lead to less unexpected behavior when running plugins nested / in parallel. # User-Facing Changes - new command: `plugin list` - new command: `plugin stop` - changed command: `version` (now lists plugin names, rather than commands) - new config: `$env.config.plugin_gc` - Plugins will keep running and be reused, at least for the configured GC period - Plugins that used mutable state in weird ways like `inc` did might misbehave until fixed - Plugins can disable GC if they need to - Had to change plugin signature to accept `&EngineInterface` so that the GC disable feature works. #12029 does this anyway, and I'm expecting (resolvable) conflicts with that # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` Because there is some specific OS behavior required for plugins to not respond to Ctrl-C directly, I've developed against and tested on both Linux and Windows to ensure that works properly. # After Submitting I think this probably needs to be in the book somewhere
2024-03-10 00:10:22 +01:00
# For setting process creation flags
"Win32_System_Threading",
] }
Reference in New Issue Copy Permalink