nushell/crates/nu-protocol/Cargo.toml

56 lines
1.7 KiB
TOML
Raw Normal View History

[package]
authors = ["The Nushell Project Developers"]
description = "Nushell's internal protocols, including its abstract syntax tree"
repository = "https://github.com/nushell/nushell/tree/main/crates/nu-protocol"
edition = "2021"
license = "MIT"
2020-07-05 22:12:44 +02:00
name = "nu-protocol"
version = "0.93.1"
2021-09-02 03:29:43 +02:00
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[lib]
bench = false
2021-09-02 03:29:43 +02:00
[dependencies]
nu-utils = { path = "../nu-utils", version = "0.93.1" }
nu-path = { path = "../nu-path", version = "0.93.1" }
nu-system = { path = "../nu-system", version = "0.93.1" }
brotli = { workspace = true, optional = true }
byte-unit = { version = "5.1", features = [ "serde" ] }
chrono = { workspace = true, features = [ "serde", "std", "unstable-locales" ], default-features = false }
chrono-humanize = { workspace = true }
fancy-regex = { workspace = true }
indexmap = { workspace = true }
lru = { workspace = true }
miette = { workspace = true, features = ["fancy-no-backtrace"] }
num-format = { workspace = true }
rmp-serde = { workspace = true, optional = true }
serde = { workspace = true, default-features = false }
thiserror = "1.0"
typetag = "0.2"
Replace `ExternalStream` with new `ByteStream` type (#12774) # Description This PR introduces a `ByteStream` type which is a `Read`-able stream of bytes. Internally, it has an enum over three different byte stream sources: ```rust pub enum ByteStreamSource { Read(Box<dyn Read + Send + 'static>), File(File), Child(ChildProcess), } ``` This is in comparison to the current `RawStream` type, which is an `Iterator<Item = Vec<u8>>` and has to allocate for each read chunk. Currently, `PipelineData::ExternalStream` serves a weird dual role where it is either external command output or a wrapper around `RawStream`. `ByteStream` makes this distinction more clear (via `ByteStreamSource`) and replaces `PipelineData::ExternalStream` in this PR: ```rust pub enum PipelineData { Empty, Value(Value, Option<PipelineMetadata>), ListStream(ListStream, Option<PipelineMetadata>), ByteStream(ByteStream, Option<PipelineMetadata>), } ``` The PR is relatively large, but a decent amount of it is just repetitive changes. This PR fixes #7017, fixes #10763, and fixes #12369. This PR also improves performance when piping external commands. Nushell should, in most cases, have competitive pipeline throughput compared to, e.g., bash. | Command | Before (MB/s) | After (MB/s) | Bash (MB/s) | | -------------------------------------------------- | -------------:| ------------:| -----------:| | `throughput \| rg 'x'` | 3059 | 3744 | 3739 | | `throughput \| nu --testbin relay o> /dev/null` | 3508 | 8087 | 8136 | # User-Facing Changes - This is a breaking change for the plugin communication protocol, because the `ExternalStreamInfo` was replaced with `ByteStreamInfo`. Plugins now only have to deal with a single input stream, as opposed to the previous three streams: stdout, stderr, and exit code. - The output of `describe` has been changed for external/byte streams. - Temporary breaking change: `bytes starts-with` no longer works with byte streams. This is to keep the PR smaller, and `bytes ends-with` already does not work on byte streams. - If a process core dumped, then instead of having a `Value::Error` in the `exit_code` column of the output returned from `complete`, it now is a `Value::Int` with the negation of the signal number. # After Submitting - Update docs and book as necessary - Release notes (e.g., plugin protocol changes) - Adapt/convert commands to work with byte streams (high priority is `str length`, `bytes starts-with`, and maybe `bytes ends-with`). - Refactor the `tee` code, Devyn has already done some work on this. --------- Co-authored-by: Devyn Cairns <devyn.cairns@gmail.com>
2024-05-16 16:11:18 +02:00
os_pipe = { workspace = true, features = ["io_safety"] }
[target.'cfg(unix)'.dependencies]
nix = { workspace = true, default-features = false, features = ["signal"] }
[features]
plugin = [
"brotli",
"rmp-serde",
]
[dev-dependencies]
serde_json = { workspace = true }
strum = "0.26"
Bump strum_macros from 0.25.3 to 0.26.1 (#11979) Bumps [strum_macros](https://github.com/Peternator7/strum) from 0.25.3 to 0.26.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/Peternator7/strum/releases">strum_macros's releases</a>.</em></p> <blockquote> <h2>v0.26.1</h2> <h2>0.26.1</h2> <ul> <li><a href="https://redirect.github.com/Peternator7/strum/pull/325">#325</a>: use <code>core</code> instead of <code>std</code> in VariantArray.</li> </ul> <h2>0.26.0</h2> <h3>Breaking Changes</h3> <ul> <li>The <code>EnumVariantNames</code> macro has been renamed <code>VariantNames</code>. The deprecation warning should steer you in the right direction for fixing the warning.</li> <li>The Iterator struct generated by EnumIter now has new bounds on it. This shouldn't break code unless you manually added the implementation in your code.</li> <li><code>Display</code> now supports format strings using named fields in the enum variant. This should be a no-op for most code. However, if you were outputting a string like <code>&quot;Hello {field}&quot;</code>, this will now be interpretted as a format string.</li> <li>EnumDiscriminant now inherits the repr and discriminant values from your main enum. This makes the discriminant type closer to a mirror of the original and that's always the goal.</li> </ul> <h3>New features</h3> <ul> <li> <p>The <code>VariantArray</code> macro has been added. This macro adds an associated constant <code>VARIANTS</code> to your enum. The constant is a <code>&amp;'static [Self]</code> slice so that you can access all the variants of your enum. This only works on enums that only have unit variants.</p> <pre lang="rust"><code>use strum::VariantArray; <p>#[derive(Debug, VariantArray)] enum Color { Red, Blue, Green, }</p> <p>fn main() { println!(&quot;{:?}&quot;, Color::VARIANTS); // prints: [&quot;Red&quot;, &quot;Blue&quot;, &quot;Green&quot;] } </code></pre></p> </li> <li> <p>The <code>EnumTable</code> macro has been <em>experimentally</em> added. This macro adds a new type that stores an item for each variant of the enum. This is useful for storing a value for each variant of an enum. This is an experimental feature because I'm not convinced the current api surface area is correct.</p> <pre lang="rust"><code>use strum::EnumTable; <p>#[derive(Copy, Clone, Debug, EnumTable)] enum Color { Red, Blue, </code></pre></p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/Peternator7/strum/blob/master/CHANGELOG.md">strum_macros's changelog</a>.</em></p> <blockquote> <h2>0.26.1</h2> <ul> <li><a href="https://redirect.github.com/Peternator7/strum/pull/325">#325</a>: use <code>core</code> instead of <code>std</code> in VariantArray.</li> </ul> <h2>0.26.0</h2> <h3>Breaking Changes</h3> <ul> <li>The <code>EnumVariantNames</code> macro has been renamed <code>VariantNames</code>. The deprecation warning should steer you in the right direction for fixing the warning.</li> <li>The Iterator struct generated by EnumIter now has new bounds on it. This shouldn't break code unless you manually added the implementation in your code.</li> <li><code>Display</code> now supports format strings using named fields in the enum variant. This should be a no-op for most code. However, if you were outputting a string like <code>&quot;Hello {field}&quot;</code>, this will now be interpretted as a format string.</li> <li>EnumDiscriminant now inherits the repr and discriminant values from your main enum. This makes the discriminant type closer to a mirror of the original and that's always the goal.</li> </ul> <h3>New features</h3> <ul> <li> <p>The <code>VariantArray</code> macro has been added. This macro adds an associated constant <code>VARIANTS</code> to your enum. The constant is a <code>&amp;'static [Self]</code> slice so that you can access all the variants of your enum. This only works on enums that only have unit variants.</p> <pre lang="rust"><code>use strum::VariantArray; <p>#[derive(Debug, VariantArray)] enum Color { Red, Blue, Green, }</p> <p>fn main() { println!(&quot;{:?}&quot;, Color::VARIANTS); // prints: [&quot;Red&quot;, &quot;Blue&quot;, &quot;Green&quot;] } </code></pre></p> </li> <li> <p>The <code>EnumTable</code> macro has been <em>experimentally</em> added. This macro adds a new type that stores an item for each variant of the enum. This is useful for storing a value for each variant of an enum. This is an experimental feature because I'm not convinced the current api surface area is correct.</p> <pre lang="rust"><code>use strum::EnumTable; <p>#[derive(Copy, Clone, Debug, EnumTable)] enum Color { Red, Blue, Green, </code></pre></p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li>See full diff in <a href="https://github.com/Peternator7/strum/commits/v0.26.1">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=strum_macros&package-manager=cargo&previous-version=0.25.3&new-version=0.26.1)](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-02-26 08:37:38 +01:00
strum_macros = "0.26"
nu-test-support = { path = "../nu-test-support", version = "0.93.1" }
pretty_assertions = { workspace = true }
rstest = { workspace = true }
Migrate to a new PWD API (#12603) This is the first PR towards migrating to a new `$env.PWD` API that returns potentially un-canonicalized paths. Refer to PR #12515 for motivations. ## New API: `EngineState::cwd()` The goal of the new API is to cover both parse-time and runtime use case, and avoid unintentional misuse. It takes an `Option<Stack>` as argument, which if supplied, will search for `$env.PWD` on the stack in additional to the engine state. I think with this design, there's less confusion over parse-time and runtime environments. If you have access to a stack, just supply it; otherwise supply `None`. ## Deprecation of other PWD-related APIs Other APIs are re-implemented using `EngineState::cwd()` and properly documented. They're marked deprecated, but their behavior is unchanged. Unused APIs are deleted, and code that accesses `$env.PWD` directly without using an API is rewritten. Deprecated APIs: * `EngineState::current_work_dir()` * `StateWorkingSet::get_cwd()` * `env::current_dir()` * `env::current_dir_str()` * `env::current_dir_const()` * `env::current_dir_str_const()` Other changes: * `EngineState::get_cwd()` (deleted) * `StateWorkingSet::list_env()` (deleted) * `repl::do_run_cmd()` (rewritten with `env::current_dir_str()`) ## `cd` and `pwd` now use logical paths by default This pulls the changes from PR #12515. It's currently somewhat broken because using non-canonicalized paths exposed a bug in our path normalization logic (Issue #12602). Once that is fixed, this should work. ## Future plans This PR needs some tests. Which test helpers should I use, and where should I put those tests? I noticed that unquoted paths are expanded within `eval_filepath()` and `eval_directory()` before they even reach the `cd` command. This means every paths is expanded twice. Is this intended? Once this PR lands, the plan is to review all usages of the deprecated APIs and migrate them to `EngineState::cwd()`. In the meantime, these usages are annotated with `#[allow(deprecated)]` to avoid breaking CI. --------- Co-authored-by: Jakub Žádník <kubouch@gmail.com>
2024-05-03 13:33:09 +02:00
tempfile = { workspace = true }
Add Stack::stdout_file and Stack::stderr_file to capture stdout/-err of external commands (#12857) # Description In this PR I added two new methods to `Stack`, `stdout_file` and `stderr_file`. These two modify the inner `StackOutDest` and set a `File` into the `stdout` and `stderr` respectively. Different to the `push_redirection` methods, these do not require to hold a guard up all the time but require ownership of the stack. This is primarly useful for applications that use `nu` as a language but not the `nushell`. This PR replaces my first attempt #12851 to add a way to capture stdout/-err of external commands. Capturing the stdout without having to write into a file is possible with crates like [`os_pipe`](https://docs.rs/os_pipe), an example for this is given in the doc comment of the `stdout_file` command and can be executed as a doctest (although it doesn't validate that you actually got any data). This implementation takes `File` as input to make it easier to implement on different operating systems without having to worry about `OwnedHandle` or `OwnedFd`. Also this doesn't expose any use `os_pipe` to not leak its types into this API, making it depend on it. As in my previous attempt, @IanManske guided me here. # User-Facing Changes This change has no effect on `nushell` and therefore no user-facing changes. # Tests + Formatting This only exposes a new way of using already existing code and has therefore no further testing. The doctest succeeds on my machine at least (x86 Windows, 64 Bit). # After Submitting All the required documentation is already part of this PR.
2024-05-13 20:48:38 +02:00
os_pipe = { workspace = true }
[package.metadata.docs.rs]
all-features = true