Extract core stuff into own crates
This commit extracts five new crates:
- nu-source, which contains the core source-code handling logic in Nu,
including Text, Span, and also the pretty.rs-based debug logic
- nu-parser, which is the parser and expander logic
- nu-protocol, which is the bulk of the types and basic conveniences
used by plugins
- nu-errors, which contains ShellError, ParseError and error handling
conveniences
- nu-textview, which is the textview plugin extracted into a crate
One of the major consequences of this refactor is that it's no longer
possible to `impl X for Spanned<Y>` outside of the `nu-source` crate, so
a lot of types became more concrete (Value became a concrete type
instead of Spanned<Value>, for example).
This also turned a number of inherent methods in the main nu crate into
plain functions (impl Value {} became a bunch of functions in the
`value` namespace in `crate::data::value`).
2019-11-26 03:30:48 +01:00
|
|
|
[package]
|
2022-03-22 21:25:38 +01:00
|
|
|
authors = ["The Nushell Project Developers"]
|
2022-04-11 20:17:06 +02:00
|
|
|
description = "Nushell's internal protocols, including its abstract syntax tree"
|
2022-08-14 14:21:20 +02:00
|
|
|
repository = "https://github.com/nushell/nushell/tree/main/crates/nu-protocol"
|
2022-03-22 21:25:38 +01:00
|
|
|
edition = "2021"
|
|
|
|
license = "MIT"
|
2020-07-05 22:12:44 +02:00
|
|
|
name = "nu-protocol"
|
2024-05-29 00:41:23 +02:00
|
|
|
version = "0.94.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
|
|
|
|
|
2023-02-12 23:22:00 +01:00
|
|
|
[lib]
|
|
|
|
bench = false
|
|
|
|
|
2021-09-02 03:29:43 +02:00
|
|
|
[dependencies]
|
2024-05-29 00:41:23 +02:00
|
|
|
nu-utils = { path = "../nu-utils", version = "0.94.1" }
|
|
|
|
nu-path = { path = "../nu-path", version = "0.94.1" }
|
|
|
|
nu-system = { path = "../nu-system", version = "0.94.1" }
|
2022-08-04 21:51:02 +02:00
|
|
|
|
2024-04-21 14:36:26 +02:00
|
|
|
brotli = { workspace = true, optional = true }
|
2024-02-06 23:20:09 +01:00
|
|
|
byte-unit = { version = "5.1", features = [ "serde" ] }
|
2024-03-07 23:40:31 +01:00
|
|
|
chrono = { workspace = true, features = [ "serde", "std", "unstable-locales" ], default-features = false }
|
2024-03-24 00:46:02 +01:00
|
|
|
chrono-humanize = { workspace = true }
|
2024-03-07 23:40:31 +01:00
|
|
|
fancy-regex = { workspace = true }
|
2024-03-24 00:46:02 +01:00
|
|
|
indexmap = { workspace = true }
|
|
|
|
lru = { workspace = true }
|
2024-03-07 23:40:31 +01:00
|
|
|
miette = { workspace = true, features = ["fancy-no-backtrace"] }
|
2024-03-24 00:46:02 +01:00
|
|
|
num-format = { workspace = true }
|
2024-04-21 14:36:26 +02:00
|
|
|
rmp-serde = { workspace = true, optional = true }
|
2024-03-24 00:46:02 +01:00
|
|
|
serde = { workspace = true, default-features = false }
|
2023-05-26 17:32:48 +02:00
|
|
|
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"] }
|
2021-11-19 03:51:42 +01:00
|
|
|
|
|
|
|
[features]
|
2024-04-21 14:36:26 +02:00
|
|
|
plugin = [
|
|
|
|
"brotli",
|
|
|
|
"rmp-serde",
|
|
|
|
]
|
2021-11-19 03:51:42 +01:00
|
|
|
|
|
|
|
[dev-dependencies]
|
2024-03-07 23:40:31 +01:00
|
|
|
serde_json = { workspace = true }
|
2024-03-10 20:31:54 +01:00
|
|
|
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>"Hello
{field}"</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>&'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!("{:?}", Color::VARIANTS); // prints:
["Red", "Blue", "Green"]
}
</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>"Hello
{field}"</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>&'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!("{:?}", Color::VARIANTS); // prints:
["Red", "Blue", "Green"]
}
</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"
|
2024-05-29 00:41:23 +02:00
|
|
|
nu-test-support = { path = "../nu-test-support", version = "0.94.1" }
|
2024-04-26 13:23:16 +02:00
|
|
|
pretty_assertions = { workspace = true }
|
2024-03-07 23:40:31 +01:00
|
|
|
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 }
|
2024-05-13 20:48:38 +02:00
|
|
|
os_pipe = { workspace = true }
|
2023-11-29 16:17:22 +01:00
|
|
|
|
|
|
|
[package.metadata.docs.rs]
|
2024-05-28 21:04:09 +02:00
|
|
|
all-features = true
|