Mirrors/nushell
2
0
Fork 0
mirror of https://github.com/nushell/nushell synced 2024-12-27 05:23:11 +00:00
Code Issues Projects Releases Packages Wiki Activity
nushell/crates/nu-plugin/Cargo.toml

36 lines
1.1 KiB
TOML
Raw Normal View History

Nu plugins now depend on nu-plugin crate.
2019-12-27 13:30:14 +00:00
[package]
Add licenses (#4893) * Add licenses * Add licenses
2022-03-22 20:25:38 +00:00
authors = ["The Nushell Project Developers"]
Update incorrect crate descriptions (#5159)
2022-04-11 18:17:06 +00: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 12:21:20 +00:00
repository = "https://github.com/nushell/nushell/tree/main/crates/nu-plugin"
Add licenses (#4893) * Add licenses * Add licenses
2022-03-22 20:25:38 +00:00
edition = "2021"
license = "MIT"
Bump to 0.16.1 (#2116)
2020-07-05 20:12:44 +00:00
name = "nu-plugin"
Bump to dev version 0.100.1 (#14328)
2024-11-14 09:04:39 +00:00
version = "0.100.1"
plugin command
2021-10-23 20:08:54 +00: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 22:22:00 +00:00
[lib]
bench = false
Setup global `cargo` lint configuration (#13691) # Description `cargo` somewhat recently gained the capability to store `lints` settings for the crate and workspace, that can override the defaults from `rustc` and `clippy` lints. This means we can enforce some lints without having to actively pass them to clippy via `cargo clippy -- -W ...`. So users just forking the repo have an easier time to follow similar requirements like our CI. ## Limitation An exception that remains is that those lints apply to both the primary code base and the tests. Thus we can't include e.g. `unwrap_used` without generating noise in the tests. Here the setup in the CI remains the most helpful. ## Included lints - Add `clippy::unchecked_duration_subtraction` (added by #12549) # User-Facing Changes Running `cargo clippy --workspace` should be closer to the CI. This has benefits for editor configured runs of clippy and saves you from having to use `toolkit` to be close to CI in more cases.
2024-08-28 21:37:17 +00:00
[lints]
workspace = true
plugin command
2021-10-23 20:08:54 +00:00
[dependencies]
Start to Add WASM Support Again (#14418) <!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> The [nushell/demo](https://github.com/nushell/demo) project successfully demonstrated running Nushell in the browser using WASM. However, the current version of Nushell cannot be easily built for the `wasm32-unknown-unknown` target, the default for `wasm-bindgen`. This PR introduces initial support for the `wasm32-unknown-unknown` target by disabling OS-dependent features such as filesystem access, IO, and platform/system-specific functionality. This separation is achieved using a new `os` feature in the following crates: - `nu-cmd-lang` - `nu-command` - `nu-engine` - `nu-protocol` The `os` feature includes all functionality that interacts with an operating system. It is enabled by default, but can be disabled using `--no-default-features`. All crates that depend on these core crates now use `--no-default-features` to allow compilation for WASM. To demonstrate compatibility, the following script builds all crates expected to work with WASM. Direct user interaction, running external commands, working with plugins, and features requiring `openssl` are out of scope for now due to their complexity or reliance on C libraries, which are difficult to compile and link in a WASM environment. ```nushell [ # compatible crates "nu-cmd-base", "nu-cmd-extra", "nu-cmd-lang", "nu-color-config", "nu-command", "nu-derive-value", "nu-engine", "nu-glob", "nu-json", "nu-parser", "nu-path", "nu-pretty-hex", "nu-protocol", "nu-std", "nu-system", "nu-table", "nu-term-grid", "nu-utils", "nuon" ] | each {cargo build -p $in --target wasm32-unknown-unknown --no-default-features} ``` ## Caveats This PR has a few caveats: 1. **`miette` and `terminal-size` Dependency Issue** `miette` depends on `terminal-size`, which uses `rustix` when the target is not Windows. However, `rustix` requires `std::os::unix`, which is unavailable in WASM. To address this, I opened a [PR](https://github.com/eminence/terminal-size/pull/68) for `terminal-size` to conditionally compile `rustix` only when the target is Unix. For now, the `Cargo.toml` includes patches to: - Use my forked version of `terminal-size`. - ~~Use an unreleased version of `miette` that depends on `terminal-size@0.4`.~~ These patches are temporary and can be removed once the upstream changes are merged and released. 2. **Test Output Adjustments** Due to the slight bump in the `miette` version, one test required adjustments to accommodate minor formatting changes in the error output, such as shifted newlines. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> This shouldn't break anything but allows using some crates for targeting `wasm32-unknown-unknown` to revive the demo page eventually. # 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` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` 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 > ``` --> - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` I did not add any extra tests, I just checked that compiling works, also when using the host target but unselecting the `os` feature. # 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. --> ~~Breaking the wasm support can be easily done by adding some `use`s or by adding a new dependency, we should definitely add some CI that also at least builds against wasm to make sure that building for it keep working.~~ I added a job to build wasm. --------- Co-authored-by: Ian Manske <ian.manske@pm.me>
2024-11-30 13:57:11 +00:00
nu-engine = { path = "../nu-engine", version = "0.100.1", features = ["plugin"] }
nu-protocol = { path = "../nu-protocol", version = "0.100.1", features = ["plugin"] }
Bump to dev version 0.100.1 (#14328)
2024-11-14 09:04:39 +00:00
nu-plugin-protocol = { path = "../nu-plugin-protocol", version = "0.100.1" }
nu-plugin-core = { path = "../nu-plugin-core", version = "0.100.1", default-features = false }
nu-utils = { path = "../nu-utils", version = "0.100.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 16:37:20 +00:00
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 17:08:12 +00:00
log = { workspace = true }
Bump thiserror from 1.0.69 to 2.0.3 (#14394) Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.69 to 2.0.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dtolnay/thiserror/releases">thiserror's releases</a>.</em></p> <blockquote> <h2>2.0.3</h2> <ul> <li>Support the same Path field being repeated in both Debug and Display representation in error message (<a href="https://redirect.github.com/dtolnay/thiserror/issues/383">#383</a>)</li> <li>Improve error message when a format trait used in error message is not implemented by some field (<a href="https://redirect.github.com/dtolnay/thiserror/issues/384">#384</a>)</li> </ul> <h2>2.0.2</h2> <ul> <li>Fix hang on invalid input inside #[error(...)] attribute (<a href="https://redirect.github.com/dtolnay/thiserror/issues/382">#382</a>)</li> </ul> <h2>2.0.1</h2> <ul> <li>Support errors that contain a dynamically sized final field (<a href="https://redirect.github.com/dtolnay/thiserror/issues/375">#375</a>)</li> <li>Improve inference of trait bounds for fields that are interpolated multiple times in an error message (<a href="https://redirect.github.com/dtolnay/thiserror/issues/377">#377</a>)</li> </ul> <h2>2.0.0</h2> <h2>Breaking changes</h2> <ul> <li> <p>Referencing keyword-named fields by a raw identifier like <code>{r#type}</code> inside a format string is no longer accepted; simply use the unraw name like <code>{type}</code> (<a href="https://redirect.github.com/dtolnay/thiserror/issues/347">#347</a>)</p> <p>This aligns thiserror with the standard library's formatting macros, which gained support for implicit argument capture later than the release of this feature in thiserror 1.x.</p> <pre lang="rust"><code>#[derive(Error, Debug)] #[error(&quot;... {type} ...&quot;)] // Before: {r#type} pub struct Error { pub r#type: Type, } </code></pre> </li> <li> <p>Trait bounds are no longer inferred on fields whose value is shadowed by an explicit named argument in a format message (<a href="https://redirect.github.com/dtolnay/thiserror/issues/345">#345</a>)</p> <pre lang="rust"><code>// Before: impl&lt;T: Octal&gt; Display for Error&lt;T&gt; // After: impl&lt;T&gt; Display for Error&lt;T&gt; #[derive(Error, Debug)] #[error(&quot;{thing:o}&quot;, thing = &quot;...&quot;)] pub struct Error&lt;T&gt; { thing: T, } </code></pre> </li> <li> <p>Tuple structs and tuple variants can no longer use numerical <code>{0}</code> <code>{1}</code> access at the same time as supplying extra positional arguments for a format message, as this makes it ambiguous whether the number refers to a tuple field vs a different positional arg (<a href="https://redirect.github.com/dtolnay/thiserror/issues/354">#354</a>)</p> <pre lang="rust"><code>#[derive(Error, Debug)] #[error(&quot;ambiguous: {0} {}&quot;, $N)] // ^^^ Not allowed, use #[error(&quot;... {0} {n}&quot;, n = $N)] pub struct TupleError(i32); </code></pre> </li> <li> <p>Code containing invocations of thiserror's <code>derive(Error)</code> must now have a direct dependency on the <code>thiserror</code> crate regardless of the error data structure's contents (<a href="https://redirect.github.com/dtolnay/thiserror/issues/368">#368</a>, <a href="https://redirect.github.com/dtolnay/thiserror/issues/369">#369</a>, <a href="https://redirect.github.com/dtolnay/thiserror/issues/370">#370</a>, <a href="https://redirect.github.com/dtolnay/thiserror/issues/372">#372</a>)</p> </li> </ul> <h2>Features</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/dtolnay/thiserror/commit/15fd26e476c5c7a2e7dc13209689c747b1db82a5"><code>15fd26e</code></a> Release 2.0.3</li> <li><a href="https://github.com/dtolnay/thiserror/commit/70460231305d82ae9a7a60424cc4d0d22d0b6e77"><code>7046023</code></a> Simplify how has_bonus_display is accumulated</li> <li><a href="https://github.com/dtolnay/thiserror/commit/9cc1d0b2514105759995dfd3c7bc4de1f0f9195b"><code>9cc1d0b</code></a> Merge pull request <a href="https://redirect.github.com/dtolnay/thiserror/issues/384">#384</a> from dtolnay/nowrap</li> <li><a href="https://github.com/dtolnay/thiserror/commit/1d040f358a34d58139f1e1c12cec575319f16edf"><code>1d040f3</code></a> Use Var wrapper only for Pointer formatting</li> <li><a href="https://github.com/dtolnay/thiserror/commit/6a6132d79bee8baf89ea0896ec6dadc3ad6b388b"><code>6a6132d</code></a> Extend no-display ui test to cover another fmt trait</li> <li><a href="https://github.com/dtolnay/thiserror/commit/a061beb9dc871144239dc3489dc012f39e13847c"><code>a061beb</code></a> Merge pull request <a href="https://redirect.github.com/dtolnay/thiserror/issues/383">#383</a> from dtolnay/both</li> <li><a href="https://github.com/dtolnay/thiserror/commit/63882935be42fbd89e7076392a4d5330e2120332"><code>6388293</code></a> Support Display and Debug of same path in error message</li> <li><a href="https://github.com/dtolnay/thiserror/commit/dc0359eeecf778da2038805431c61010e7aa957e"><code>dc0359e</code></a> Defer binding_value construction</li> <li><a href="https://github.com/dtolnay/thiserror/commit/520343e37d890e0a4b0c6e1427e8164c43ce1c7d"><code>520343e</code></a> Add test of Debug and Display of paths</li> <li><a href="https://github.com/dtolnay/thiserror/commit/49be39dee10d7fce1d4b2f7f6b6010f2b309794e"><code>49be39d</code></a> Release 2.0.2</li> <li>Additional commits viewable in <a href="https://github.com/dtolnay/thiserror/compare/1.0.69...2.0.3">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=thiserror&package-manager=cargo&previous-version=1.0.69&new-version=2.0.3)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2024-11-20 01:19:37 +00:00
thiserror = "2.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 17:08:12 +00:00
[dev-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-23 23:46:02 +00:00
serde = { workspace = true }
Bidirectional communication and streams for plugins (#11911)
2024-02-25 22:32:50 +00:00
typetag = "0.2"
Local socket mode and foreground terminal control for plugins (#12448) # Description Adds support for running plugins using local socket communication instead of stdio. This will be an optional thing that not all plugins have to support. This frees up stdio for use to make plugins that use stdio to create terminal UIs, cc @amtoine, @fdncred. This uses the [`interprocess`](https://crates.io/crates/interprocess) crate (298 stars, MIT license, actively maintained), which seems to be the best option for cross-platform local socket support in Rust. On Windows, a local socket name is provided. On Unixes, it's a path. The socket name is kept to a relatively small size because some operating systems have pretty strict limits on the whole path (~100 chars), so on macOS for example we prefer `/tmp/nu.{pid}.{hash64}.sock` where the hash includes the plugin filename and timestamp to be unique enough. This also adds an API for moving plugins in and out of the foreground group, which is relevant for Unixes where direct terminal control depends on that. TODO: - [x] Generate local socket path according to OS conventions - [x] Add support for passing `--local-socket` to the plugin executable instead of `--stdio`, and communicating over that instead - [x] Test plugins that were broken, including [amtoine/nu_plugin_explore](https://github.com/amtoine/nu_plugin_explore) - [x] Automatically upgrade to using local sockets when supported, falling back if it doesn't work, transparently to the user without any visible error messages - Added protocol feature: `LocalSocket` - [x] Reset preferred mode to `None` on `register` - [x] Allow plugins to detect whether they're running on a local socket and can use stdio freely, so that TUI plugins can just produce an error message otherwise - Implemented via `EngineInterface::is_using_stdio()` - [x] Clean up foreground state when plugin command exits on the engine side too, not just whole plugin - [x] Make sure tests for failure cases work as intended - `nu_plugin_stress_internals` added # User-Facing Changes - TUI plugins work - Non-Rust plugins could optionally choose to use this - This might behave differently, so will need to test it carefully across different operating systems # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting - [ ] Document local socket option in plugin contrib docs - [ ] Document how to do a terminal UI plugin in plugin contrib docs - [ ] Document: `EnterForeground` engine call - [ ] Document: `LeaveForeground` engine call - [ ] Document: `LocalSocket` protocol feature
2024-04-15 18:28:18 +00:00
[features]
default = ["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 17:08:12 +00:00
local-socket = ["nu-plugin-core/local-socket"]
Local socket mode and foreground terminal control for plugins (#12448) # Description Adds support for running plugins using local socket communication instead of stdio. This will be an optional thing that not all plugins have to support. This frees up stdio for use to make plugins that use stdio to create terminal UIs, cc @amtoine, @fdncred. This uses the [`interprocess`](https://crates.io/crates/interprocess) crate (298 stars, MIT license, actively maintained), which seems to be the best option for cross-platform local socket support in Rust. On Windows, a local socket name is provided. On Unixes, it's a path. The socket name is kept to a relatively small size because some operating systems have pretty strict limits on the whole path (~100 chars), so on macOS for example we prefer `/tmp/nu.{pid}.{hash64}.sock` where the hash includes the plugin filename and timestamp to be unique enough. This also adds an API for moving plugins in and out of the foreground group, which is relevant for Unixes where direct terminal control depends on that. TODO: - [x] Generate local socket path according to OS conventions - [x] Add support for passing `--local-socket` to the plugin executable instead of `--stdio`, and communicating over that instead - [x] Test plugins that were broken, including [amtoine/nu_plugin_explore](https://github.com/amtoine/nu_plugin_explore) - [x] Automatically upgrade to using local sockets when supported, falling back if it doesn't work, transparently to the user without any visible error messages - Added protocol feature: `LocalSocket` - [x] Reset preferred mode to `None` on `register` - [x] Allow plugins to detect whether they're running on a local socket and can use stdio freely, so that TUI plugins can just produce an error message otherwise - Implemented via `EngineInterface::is_using_stdio()` - [x] Clean up foreground state when plugin command exits on the engine side too, not just whole plugin - [x] Make sure tests for failure cases work as intended - `nu_plugin_stress_internals` added # User-Facing Changes - TUI plugins work - Non-Rust plugins could optionally choose to use this - This might behave differently, so will need to test it carefully across different operating systems # Tests + Formatting - :green_circle: `toolkit fmt` - :green_circle: `toolkit clippy` - :green_circle: `toolkit test` - :green_circle: `toolkit test stdlib` # After Submitting - [ ] Document local socket option in plugin contrib docs - [ ] Document how to do a terminal UI plugin in plugin contrib docs - [ ] Document: `EnterForeground` engine call - [ ] Document: `LeaveForeground` engine call - [ ] Document: `LocalSocket` protocol feature
2024-04-15 18:28:18 +00:00
[target.'cfg(target_family = "unix")'.dependencies]
# For setting the process group ID (EnterForeground / LeaveForeground)
Bump to version 0.99.0 (#14094) <!-- if this PR closes one or more issues, you can automatically link the PR with them by using one of the [*linking keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword), e.g. - this PR should close #xxxx - fixes #xxxx you can also mention related issues, PRs or discussions! --> # Description <!-- Thank you for improving Nushell. Please, check our [contributing guide](../CONTRIBUTING.md) and talk to the core team before making major changes. Description of your pull request goes here. **Provide examples and/or screenshots** if your changes affect the user experience. --> # 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` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` 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. -->
2024-10-15 19:01:08 +00:00
nix = { workspace = true, default-features = false, features = ["process"] }
Reference in a new issue Copy permalink