2019-05-10 18:59:12 +02:00
|
|
|
[package]
|
2022-03-13 19:30:27 +01:00
|
|
|
authors = ["The Nushell Project Developers"]
|
2023-05-20 14:57:51 +02:00
|
|
|
build = "scripts/build.rs"
|
2020-07-05 22:12:44 +02:00
|
|
|
default-run = "nu"
|
2020-04-06 09:16:14 +02:00
|
|
|
description = "A new type of shell"
|
2020-07-05 22:12:44 +02:00
|
|
|
documentation = "https://www.nushell.sh/book/"
|
2023-01-05 13:24:42 +01:00
|
|
|
edition = "2021"
|
2020-07-05 22:12:44 +02:00
|
|
|
exclude = ["images"]
|
|
|
|
|
homepage = "https://www.nushell.sh"
|
|
|
|
|
license = "MIT"
|
|
|
|
|
name = "nu"
|
2019-07-16 21:17:46 +02:00
|
|
|
repository = "https://github.com/nushell/nushell"
|
2024-04-10 23:41:38 +02:00
|
|
|
rust-version = "1.77.2"
|
2024-06-26 03:26:07 +02:00
|
|
|
version = "0.95.1"
|
2021-06-30 03:42:56 +02:00
|
|
|
|
|
|
|
|
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
|
|
|
|
|
|
2022-11-23 17:46:06 +01:00
|
|
|
[package.metadata.binstall]
|
|
|
|
|
pkg-url = "{ repo }/releases/download/{ version }/{ name }-{ version }-{ target }.{ archive-format }"
|
|
|
|
|
pkg-fmt = "tgz"
|
|
|
|
|
|
|
|
|
|
[package.metadata.binstall.overrides.x86_64-pc-windows-msvc]
|
|
|
|
|
pkg-fmt = "zip"
|
|
|
|
|
|
2021-08-25 21:29:36 +02:00
|
|
|
[workspace]
|
2021-10-28 08:12:33 +02:00
|
|
|
members = [
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu-cli",
|
|
|
|
|
"crates/nu-engine",
|
|
|
|
|
"crates/nu-parser",
|
|
|
|
|
"crates/nu-system",
|
|
|
|
|
"crates/nu-cmd-base",
|
|
|
|
|
"crates/nu-cmd-extra",
|
|
|
|
|
"crates/nu-cmd-lang",
|
2024-04-21 14:36:26 +02:00
|
|
|
"crates/nu-cmd-plugin",
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu-command",
|
|
|
|
|
"crates/nu-color-config",
|
|
|
|
|
"crates/nu-explore",
|
|
|
|
|
"crates/nu-json",
|
|
|
|
|
"crates/nu-lsp",
|
|
|
|
|
"crates/nu-pretty-hex",
|
|
|
|
|
"crates/nu-protocol",
|
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-18 01:05:11 +02:00
|
|
|
"crates/nu-derive-value",
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu-plugin",
|
2024-04-27 19:08:12 +02:00
|
|
|
"crates/nu-plugin-core",
|
|
|
|
|
"crates/nu-plugin-engine",
|
|
|
|
|
"crates/nu-plugin-protocol",
|
2024-03-23 19:29:54 +01:00
|
|
|
"crates/nu-plugin-test-support",
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu_plugin_inc",
|
|
|
|
|
"crates/nu_plugin_gstat",
|
|
|
|
|
"crates/nu_plugin_example",
|
|
|
|
|
"crates/nu_plugin_query",
|
|
|
|
|
"crates/nu_plugin_custom_values",
|
|
|
|
|
"crates/nu_plugin_formats",
|
2024-04-10 02:31:43 +02:00
|
|
|
"crates/nu_plugin_polars",
|
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 20:28:18 +02:00
|
|
|
"crates/nu_plugin_stress_internals",
|
2024-03-07 23:40:31 +01:00
|
|
|
"crates/nu-std",
|
|
|
|
|
"crates/nu-table",
|
|
|
|
|
"crates/nu-term-grid",
|
|
|
|
|
"crates/nu-test-support",
|
|
|
|
|
"crates/nu-utils",
|
create `nuon` crate from `from nuon` and `to nuon` (#12553)
# Description
playing with the NUON format in Rust code in some plugins, we agreed
with the team it was a great time to create a standalone NUON format to
allow Rust devs to use this Nushell file format.
> **Note**
> this PR almost copy-pastes the code from
`nu_commands/src/formats/from/nuon.rs` and
`nu_commands/src/formats/to/nuon.rs` to `nuon/src/from.rs` and
`nuon/src/to.rs`, with minor tweaks to make then standalone functions,
e.g. remove the rest of the command implementations
### TODO
- [x] add tests
- [x] add documentation
# User-Facing Changes
devs will have access to a new crate, `nuon`, and two functions,
`from_nuon` and `to_nuon`
```rust
from_nuon(
input: &str,
span: Option<Span>,
) -> Result<Value, ShellError>
```
```rust
to_nuon(
input: &Value,
raw: bool,
tabs: Option<usize>,
indent: Option<usize>,
span: Option<Span>,
) -> Result<String, ShellError>
```
# Tests + Formatting
i've basically taken all the tests from
`crates/nu-command/tests/format_conversions/nuon.rs` and converted them
to use `from_nuon` and `to_nuon` instead of Nushell commands
- i've created a `nuon_end_to_end` to run both conversions with an
optional middle value to check that all is fine
> **Note**
> the `nuon::tests::read_code_should_fail_rather_than_panic` test does
give different results locally and in the CI...
> i've left it ignored with comments to help future us :)
# After Submitting
mention that in the release notes for sure!!
2024-04-19 13:54:16 +02:00
|
|
|
"crates/nuon",
|
2021-10-28 08:12:33 +02:00
|
|
|
]
|
2021-08-25 21:29:36 +02:00
|
|
|
|
2024-03-07 23:40:31 +01:00
|
|
|
[workspace.dependencies]
|
2024-03-24 00:46:02 +01:00
|
|
|
alphanumeric-sort = "1.5"
|
|
|
|
|
ansi-str = "0.8"
|
`explore`: adopt `anyhow`, support `CustomValue`, remove help system (#12692)
This PR:
1. Adds basic support for `CustomValue` to `explore`. Previously `open
foo.db | explore` didn't really work, now we "materialize" the whole
database to a `Value` before loading it
2. Adopts `anyhow` for error handling in `explore`. Previously we were
kind of rolling our own version of `anyhow` by shoving all errors into a
`std::io::Error`; I think this is much nicer. This was necessary because
as part of 1), collecting input is now fallible...
3. Removes a lot of `explore`'s fancy command help system.
- Previously each command (`:help`, `:try`, etc.) had a sophisticated
help system with examples etc... but this was not very visible to users.
You had to know to run `:help :try` or view a list of commands with
`:help :`
- As discussed previously, we eventually want to move to a less modal
approach for `explore`, without the Vim-like commands. And so I don't
think it's worth keeping this command help system around (it's
intertwined with other stuff, and making these changes would have been
harder if keeping it).
4. Rename the `--reverse` flag to `--tail`. The flag scrolls to the end
of the data, which IMO is described better by "tail"
5. Does some renaming+commenting to clear up things I found difficult to
understand when navigating the `explore` code
I initially thought 1) would be just a few lines, and then this PR blew
up into much more extensive changes 😅
## Before
The whole database was being displayed as a single Nuon/JSON line 🤔
## After
The database gets displayed like a record
## Future work
It is sort of annoying that we have to load a whole SQLite database into
memory to make this work; it will be impractical for large databases.
I'd like to explore improvements to `CustomValue` that can make this
work more efficiently.
2024-05-02 00:34:37 +02:00
|
|
|
anyhow = "1.0.82"
|
2024-05-04 17:16:40 +02:00
|
|
|
base64 = "0.22.1"
|
2024-03-24 00:46:02 +01:00
|
|
|
bracoxide = "0.1.2"
|
2024-04-21 14:36:26 +02:00
|
|
|
brotli = "5.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
byteorder = "1.5"
|
|
|
|
|
bytesize = "1.3"
|
|
|
|
|
calamine = "0.24.0"
|
|
|
|
|
chardetng = "0.1.17"
|
2024-05-04 20:16:20 +02:00
|
|
|
chrono = { default-features = false, version = "0.4.34" }
|
2024-03-24 00:46:02 +01:00
|
|
|
chrono-humanize = "0.2.3"
|
|
|
|
|
chrono-tz = "0.8"
|
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-18 01:05:11 +02:00
|
|
|
convert_case = "0.6"
|
2024-03-24 00:46:02 +01:00
|
|
|
crossbeam-channel = "0.5.8"
|
2024-03-07 23:40:31 +01:00
|
|
|
crossterm = "0.27"
|
2024-03-24 00:46:02 +01:00
|
|
|
csv = "1.3"
|
2024-03-07 23:40:31 +01:00
|
|
|
ctrlc = "3.4"
|
2024-06-29 23:12:34 +02:00
|
|
|
deunicode = "1.6.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
dialoguer = { default-features = false, version = "0.11" }
|
|
|
|
|
digest = { default-features = false, version = "0.10" }
|
|
|
|
|
dirs-next = "2.0"
|
|
|
|
|
dtparse = "2.0"
|
|
|
|
|
encoding_rs = "0.8"
|
2024-03-07 23:40:31 +01:00
|
|
|
fancy-regex = "0.13"
|
2024-03-24 00:46:02 +01:00
|
|
|
filesize = "0.2"
|
|
|
|
|
filetime = "0.2"
|
|
|
|
|
fs_extra = "1.3"
|
|
|
|
|
fuzzy-matcher = "0.3"
|
|
|
|
|
hamcrest2 = "0.3"
|
|
|
|
|
heck = "0.5.0"
|
|
|
|
|
human-date-parser = "0.1.1"
|
|
|
|
|
indexmap = "2.2"
|
|
|
|
|
indicatif = "0.17"
|
2024-06-20 10:10:27 +02:00
|
|
|
interprocess = "2.2.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
is_executable = "1.0"
|
|
|
|
|
itertools = "0.12"
|
|
|
|
|
libc = "0.2"
|
|
|
|
|
libproc = "0.14"
|
2024-03-07 23:40:31 +01:00
|
|
|
log = "0.4"
|
2024-03-24 00:46:02 +01:00
|
|
|
lru = "0.12"
|
|
|
|
|
lscolors = { version = "0.17", default-features = false }
|
|
|
|
|
lsp-server = "0.7.5"
|
|
|
|
|
lsp-types = "0.95.0"
|
|
|
|
|
mach2 = "0.4"
|
2024-04-12 22:56:40 +02:00
|
|
|
md5 = { version = "0.10", package = "md-5" }
|
2024-03-13 02:35:40 +01:00
|
|
|
miette = "7.2"
|
2024-03-24 00:46:02 +01:00
|
|
|
mime = "0.3"
|
|
|
|
|
mime_guess = "2.0"
|
|
|
|
|
mockito = { version = "1.4", default-features = false }
|
|
|
|
|
native-tls = "0.2"
|
2024-03-27 16:43:37 +01:00
|
|
|
nix = { version = "0.28", default-features = false }
|
2024-03-24 00:46:02 +01:00
|
|
|
notify-debouncer-full = { version = "0.3", default-features = false }
|
2024-03-07 23:40:31 +01:00
|
|
|
nu-ansi-term = "0.50.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
num-format = "0.4"
|
|
|
|
|
num-traits = "0.2"
|
|
|
|
|
omnipath = "0.1"
|
2024-03-07 23:40:31 +01:00
|
|
|
once_cell = "1.18"
|
2024-07-03 03:23:11 +02:00
|
|
|
open = "5.2"
|
2024-06-07 02:08:02 +02:00
|
|
|
os_pipe = { version = "1.2", features = ["io_safety"] }
|
2024-03-07 23:40:31 +01:00
|
|
|
pathdiff = "0.2"
|
|
|
|
|
percent-encoding = "2"
|
2024-04-26 13:23:16 +02:00
|
|
|
pretty_assertions = "1.4"
|
2024-03-24 00:46:02 +01:00
|
|
|
print-positions = "0.6"
|
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-18 01:05:11 +02:00
|
|
|
proc-macro-error = { version = "1.0", default-features = false }
|
|
|
|
|
proc-macro2 = "1.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
procfs = "0.16.0"
|
|
|
|
|
pwd = "1.3"
|
|
|
|
|
quick-xml = "0.31.0"
|
|
|
|
|
quickcheck = "1.0"
|
|
|
|
|
quickcheck_macros = "1.0"
|
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-18 01:05:11 +02:00
|
|
|
quote = "1.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
rand = "0.8"
|
|
|
|
|
ratatui = "0.26"
|
2024-03-27 07:44:17 +01:00
|
|
|
rayon = "1.10"
|
2024-05-01 00:32:54 +02:00
|
|
|
reedline = "0.32.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
regex = "1.9.5"
|
2024-04-26 13:23:16 +02:00
|
|
|
rmp = "0.8"
|
2024-05-02 02:26:00 +02:00
|
|
|
rmp-serde = "1.3"
|
2024-03-24 00:46:02 +01:00
|
|
|
ropey = "1.6.1"
|
|
|
|
|
roxmltree = "0.19"
|
2024-03-07 23:40:31 +01:00
|
|
|
rstest = { version = "0.18", default-features = false }
|
2024-03-24 00:46:02 +01:00
|
|
|
rusqlite = "0.31"
|
2024-05-15 03:06:09 +02:00
|
|
|
rust-embed = "8.4.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
same-file = "1.0"
|
|
|
|
|
serde = { version = "1.0", default-features = false }
|
2024-03-07 23:40:31 +01:00
|
|
|
serde_json = "1.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
serde_urlencoded = "0.7.1"
|
|
|
|
|
serde_yaml = "0.9"
|
|
|
|
|
sha2 = "0.10"
|
|
|
|
|
strip-ansi-escapes = "0.2.0"
|
Add derive macros for `FromValue` and `IntoValue` to ease the use of `Value`s in Rust code (#13031)
# Description
After discussing with @sholderbach the cumbersome usage of
`nu_protocol::Value` in Rust, I created a derive macro to simplify it.
I’ve added a new crate called `nu-derive-value`, which includes two
macros, `IntoValue` and `FromValue`. These are re-exported in
`nu-protocol` and should be encouraged to be used via that re-export.
The macros ensure that all types can easily convert from and into
`Value`. For example, as a plugin author, you can define your plugin
configuration using a Rust struct and easily convert it using
`FromValue`. This makes plugin configuration less of a hassle.
I introduced the `IntoValue` trait for a standardized approach to
converting values into `Value` (and a fallible variant `TryIntoValue`).
This trait could potentially replace existing `into_value` methods.
Along with this, I've implemented `FromValue` for several standard types
and refined other implementations to use blanket implementations where
applicable.
I made these design choices with input from @devyn.
There are more improvements possible, but this is a solid start and the
PR is already quite substantial.
# User-Facing Changes
For `nu-protocol` users, these changes simplify the handling of
`Value`s. There are no changes for end-users of nushell itself.
# Tests + Formatting
Documenting the macros itself is not really possible, as they cannot
really reference any other types since they are the root of the
dependency graph. The standard library has the same problem
([std::Debug](https://doc.rust-lang.org/stable/std/fmt/derive.Debug.html)).
However I documented the `FromValue` and `IntoValue` traits completely.
For testing, I made of use `proc-macro2` in the derive macro code. This
would allow testing the generated source code. Instead I just tested
that the derived functionality is correct. This is done in
`nu_protocol::value::test_derive`, as a consumer of `nu-derive-value`
needs to do the testing of the macro usage. I think that these tests
should provide a stable baseline so that users can be sure that the impl
works.
# After Submitting
With these macros available, we can probably use them in some examples
for plugins to showcase the use of them.
2024-06-18 01:05:11 +02:00
|
|
|
syn = "2.0"
|
2024-03-07 23:40:31 +01:00
|
|
|
sysinfo = "0.30"
|
2024-03-24 00:46:02 +01:00
|
|
|
tabled = { version = "0.14.0", default-features = false }
|
2024-03-07 23:40:31 +01:00
|
|
|
tempfile = "3.10"
|
2024-03-24 00:46:02 +01:00
|
|
|
terminal_size = "0.3"
|
|
|
|
|
titlecase = "2.0"
|
|
|
|
|
toml = "0.8"
|
|
|
|
|
trash = "3.3"
|
|
|
|
|
umask = "2.1"
|
2024-03-07 23:40:31 +01:00
|
|
|
unicode-segmentation = "1.11"
|
2024-03-24 00:46:02 +01:00
|
|
|
unicode-width = "0.1"
|
|
|
|
|
ureq = { version = "2.9", default-features = false }
|
|
|
|
|
url = "2.2"
|
2024-07-03 13:49:18 +02:00
|
|
|
uu_cp = "0.0.27"
|
|
|
|
|
uu_mkdir = "0.0.27"
|
|
|
|
|
uu_mktemp = "0.0.27"
|
|
|
|
|
uu_mv = "0.0.27"
|
|
|
|
|
uu_whoami = "0.0.27"
|
|
|
|
|
uu_uname = "0.0.27"
|
|
|
|
|
uucore = "0.0.27"
|
2024-06-26 08:43:46 +02:00
|
|
|
uuid = "1.9.1"
|
2024-03-24 00:46:02 +01:00
|
|
|
v_htmlescape = "0.15.0"
|
|
|
|
|
wax = "0.6"
|
2024-03-07 23:40:31 +01:00
|
|
|
which = "6.0.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
windows = "0.54"
|
|
|
|
|
winreg = "0.52"
|
2024-03-07 23:40:31 +01:00
|
|
|
|
2021-06-30 03:42:56 +02:00
|
|
|
[dependencies]
|
2024-06-26 03:26:07 +02:00
|
|
|
nu-cli = { path = "./crates/nu-cli", version = "0.95.1" }
|
|
|
|
|
nu-cmd-base = { path = "./crates/nu-cmd-base", version = "0.95.1" }
|
|
|
|
|
nu-cmd-lang = { path = "./crates/nu-cmd-lang", version = "0.95.1" }
|
|
|
|
|
nu-cmd-plugin = { path = "./crates/nu-cmd-plugin", version = "0.95.1", optional = true }
|
|
|
|
|
nu-cmd-extra = { path = "./crates/nu-cmd-extra", version = "0.95.1" }
|
|
|
|
|
nu-command = { path = "./crates/nu-command", version = "0.95.1" }
|
|
|
|
|
nu-engine = { path = "./crates/nu-engine", version = "0.95.1" }
|
|
|
|
|
nu-explore = { path = "./crates/nu-explore", version = "0.95.1" }
|
|
|
|
|
nu-lsp = { path = "./crates/nu-lsp/", version = "0.95.1" }
|
|
|
|
|
nu-parser = { path = "./crates/nu-parser", version = "0.95.1" }
|
|
|
|
|
nu-path = { path = "./crates/nu-path", version = "0.95.1" }
|
|
|
|
|
nu-plugin-engine = { path = "./crates/nu-plugin-engine", optional = true, version = "0.95.1" }
|
|
|
|
|
nu-protocol = { path = "./crates/nu-protocol", version = "0.95.1" }
|
|
|
|
|
nu-std = { path = "./crates/nu-std", version = "0.95.1" }
|
|
|
|
|
nu-system = { path = "./crates/nu-system", version = "0.95.1" }
|
|
|
|
|
nu-utils = { path = "./crates/nu-utils", version = "0.95.1" }
|
2023-12-21 16:41:31 +01:00
|
|
|
|
2024-03-07 23:40:31 +01:00
|
|
|
reedline = { workspace = true, features = ["bashisms", "sqlite"] }
|
2022-09-19 16:28:36 +02:00
|
|
|
|
2024-03-07 23:40:31 +01:00
|
|
|
crossterm = { workspace = true }
|
|
|
|
|
ctrlc = { workspace = true }
|
2024-06-11 21:10:31 +02:00
|
|
|
dirs-next = { workspace = true }
|
2024-03-07 23:40:31 +01:00
|
|
|
log = { workspace = true }
|
|
|
|
|
miette = { workspace = true, features = ["fancy-no-backtrace", "fancy"] }
|
2024-05-21 07:47:24 +02:00
|
|
|
mimalloc = { version = "0.1.42", default-features = false, optional = true }
|
2024-03-07 23:40:31 +01:00
|
|
|
serde_json = { workspace = true }
|
2023-05-26 17:32:48 +02:00
|
|
|
simplelog = "0.12"
|
|
|
|
|
time = "0.3"
|
2022-02-22 16:55:28 +01:00
|
|
|
|
2022-05-26 20:28:59 +02:00
|
|
|
[target.'cfg(not(target_os = "windows"))'.dependencies]
|
|
|
|
|
# Our dependencies don't use OpenSSL on Windows
|
2023-05-26 17:32:48 +02:00
|
|
|
openssl = { version = "0.10", features = ["vendored"], optional = true }
|
2022-05-26 20:28:59 +02:00
|
|
|
|
2022-10-16 23:51:15 +02:00
|
|
|
[target.'cfg(windows)'.build-dependencies]
|
2023-04-26 14:14:55 +02:00
|
|
|
winresource = "0.1"
|
2022-10-16 23:51:15 +02:00
|
|
|
|
|
|
|
|
[target.'cfg(target_family = "unix")'.dependencies]
|
2024-03-07 23:40:31 +01:00
|
|
|
nix = { workspace = true, default-features = false, features = [
|
|
|
|
|
"signal",
|
|
|
|
|
"process",
|
|
|
|
|
"fs",
|
|
|
|
|
"term",
|
`string | fill` counts clusters, not graphemes; and doesn't count ANSI escape codes (#8134)
Enhancement of new `fill` command (#7846) to handle content including
ANSI escape codes for formatting or multi-code-point Unicode grapheme
clusters.
In both of these cases, the content is (many) bytes longer than its
visible length, and `fill` was counting the extra bytes so not adding
enough fill characters.
# Description
This script:
```rust
# the teacher emoji `\u{1F9D1}\u{200D}\u{1F3EB}` is 3 code points, but only 1 print position wide.
echo "This output should be 3 print positions wide, with leading and trailing `+`"
$"\u{1F9D1}\u{200D}\u{1F3EB}" | fill -c "+" -w 3 -a "c"
echo "This output should be 3 print positions wide, with leading and trailing `+`"
$"(ansi green)a(ansi reset)" | fill -c "+" -w 3 -a c
echo ""
```
Was producing this output:
```rust
This output should be 3 print positions wide, with leading and trailing `+`
🧑🏫
This output should be 3 print positions wide, with leading and trailing `+`
a
```
After this PR, it produces this output:
```rust
This output should be 3 print positions wide, with leading and trailing `+`
+🧑🏫+
This output should be 3 print positions wide, with leading and trailing `+`
+a+
```
# User-Facing Changes
Users may have to undo fixes they may have introduced to work around the
former behavior. I have one such in my prompt string that I can now
revert.
# Tests + Formatting
Don't forget to add tests that cover your changes.
-- Done
Make sure you've run and fixed any issues with these commands:
- [x] `cargo fmt --all -- --check` to check standard code formatting
(`cargo fmt --all` applies these changes)
- [x] `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
- [x] `cargo test --workspace` to check that all tests pass
# After Submitting
`fill` command not documented in the book, and it still talks about `str
lpad/rpad`. I'll fix.
Note added dependency on a new library `print-positions`, which is an
iterator that yields a complete print position (cluster + Ansi sequence)
per call. Should this be vendored?
2023-02-20 13:32:20 +01:00
|
|
|
] }
|
2022-10-16 23:51:15 +02:00
|
|
|
|
2021-07-30 22:02:16 +02:00
|
|
|
[dev-dependencies]
|
2024-06-26 03:26:07 +02:00
|
|
|
nu-test-support = { path = "./crates/nu-test-support", version = "0.95.1" }
|
|
|
|
|
nu-plugin-protocol = { path = "./crates/nu-plugin-protocol", version = "0.95.1" }
|
|
|
|
|
nu-plugin-core = { path = "./crates/nu-plugin-core", version = "0.95.1" }
|
2023-05-26 17:32:48 +02:00
|
|
|
assert_cmd = "2.0"
|
2024-03-24 00:46:02 +01:00
|
|
|
dirs-next = { workspace = true }
|
Tango migration (#12469)
# Description
This PR migrates the benchmark suit to Tango. Its different compared to
other framework because it require 2 binaries, to run to do A/B
benchmarking, this is currently limited to Linux, Max, (Windows require
rustc nightly flag), by switching between two suits it can reduce noise
and run the code "almost" concurrently. I have have been in contact with
the maintainer, and bases this on the dev branch, as it had a newer API
simular to criterion. This framework compared to Divan also have a
simple file dump system if we want to generate graphs, do other analysis
on later. I think overall this crate is very nice, a lot faster to
compile and run then criterion, that's for sure.
2024-05-05 17:53:48 +02:00
|
|
|
tango-bench = "0.5"
|
2024-04-26 13:23:16 +02:00
|
|
|
pretty_assertions = { workspace = true }
|
2024-03-07 23:40:31 +01:00
|
|
|
rstest = { workspace = true, default-features = false }
|
2024-04-24 14:01:20 +02:00
|
|
|
serial_test = "3.1"
|
2024-03-07 23:40:31 +01:00
|
|
|
tempfile = { workspace = true }
|
2021-12-07 21:06:34 +01:00
|
|
|
|
|
|
|
|
[features]
|
2023-01-23 19:57:40 +01:00
|
|
|
plugin = [
|
2024-04-27 19:08:12 +02:00
|
|
|
"nu-plugin-engine",
|
2024-04-21 14:36:26 +02:00
|
|
|
"nu-cmd-plugin",
|
2024-03-07 23:40:31 +01:00
|
|
|
"nu-cli/plugin",
|
|
|
|
|
"nu-parser/plugin",
|
|
|
|
|
"nu-command/plugin",
|
|
|
|
|
"nu-protocol/plugin",
|
|
|
|
|
"nu-engine/plugin",
|
2023-01-23 19:57:40 +01:00
|
|
|
]
|
2024-01-20 15:04:06 +01:00
|
|
|
default = ["default-no-clipboard", "system-clipboard"]
|
|
|
|
|
# Enables convenient omitting of the system-clipboard feature, as it leads to problems in ci on linux
|
|
|
|
|
# See https://github.com/nushell/nushell/pull/11535
|
|
|
|
|
default-no-clipboard = [
|
2024-03-07 23:40:31 +01:00
|
|
|
"plugin",
|
|
|
|
|
"trash-support",
|
|
|
|
|
"sqlite",
|
|
|
|
|
"mimalloc",
|
2024-01-20 15:04:06 +01:00
|
|
|
]
|
2021-12-07 21:06:34 +01:00
|
|
|
stable = ["default"]
|
2023-06-14 23:12:55 +02:00
|
|
|
# NOTE: individual features are also passed to `nu-cmd-lang` that uses them to generate the feature matrix in the `version` command
|
2022-11-21 18:24:25 +01:00
|
|
|
|
2023-10-11 01:13:28 +02:00
|
|
|
# Enable to statically link OpenSSL (perl is required, to build OpenSSL https://docs.rs/openssl/latest/openssl/);
|
2023-09-09 22:34:07 +02:00
|
|
|
# otherwise the system version will be used. Not enabled by default because it takes a while to build
|
2023-05-22 17:42:38 +02:00
|
|
|
static-link-openssl = ["dep:openssl", "nu-cmd-lang/static-link-openssl"]
|
2021-12-07 21:06:34 +01:00
|
|
|
|
2023-06-15 00:27:12 +02:00
|
|
|
mimalloc = ["nu-cmd-lang/mimalloc", "dep:mimalloc"]
|
2024-04-18 16:33:41 +02:00
|
|
|
system-clipboard = [
|
|
|
|
|
"reedline/system_clipboard",
|
|
|
|
|
"nu-cli/system-clipboard",
|
|
|
|
|
"nu-cmd-lang/system-clipboard",
|
|
|
|
|
]
|
2023-06-15 00:27:12 +02:00
|
|
|
|
2021-12-07 21:06:34 +01:00
|
|
|
# Stable (Default)
|
2023-05-22 17:42:38 +02:00
|
|
|
trash-support = ["nu-command/trash-support", "nu-cmd-lang/trash-support"]
|
2022-01-20 19:02:53 +01:00
|
|
|
|
2022-11-23 01:58:11 +01:00
|
|
|
# SQLite commands for nushell
|
2023-05-22 17:42:38 +02:00
|
|
|
sqlite = ["nu-command/sqlite", "nu-cmd-lang/sqlite"]
|
2022-04-24 11:29:21 +02:00
|
|
|
|
2021-12-07 21:06:34 +01:00
|
|
|
[profile.release]
|
2023-01-23 19:57:40 +01:00
|
|
|
opt-level = "s" # Optimize for size
|
2022-02-28 13:13:24 +01:00
|
|
|
strip = "debuginfo"
|
2022-03-10 14:37:24 +01:00
|
|
|
lto = "thin"
|
2022-02-28 13:13:24 +01:00
|
|
|
|
2022-03-16 23:21:06 +01:00
|
|
|
# build with `cargo build --profile profiling`
|
2022-02-28 13:13:24 +01:00
|
|
|
# to analyze performance with tooling like linux perf
|
|
|
|
|
[profile.profiling]
|
|
|
|
|
inherits = "release"
|
|
|
|
|
strip = false
|
|
|
|
|
debug = true
|
2021-12-07 21:06:34 +01:00
|
|
|
|
2022-05-16 06:02:11 +02:00
|
|
|
# build with `cargo build --profile ci`
|
|
|
|
|
# to analyze performance with tooling like linux perf
|
|
|
|
|
[profile.ci]
|
|
|
|
|
inherits = "dev"
|
|
|
|
|
strip = false
|
|
|
|
|
debug = false
|
|
|
|
|
|
2019-12-10 01:05:40 +01:00
|
|
|
# Main nu binary
|
2019-06-27 06:56:48 +02:00
|
|
|
[[bin]]
|
|
|
|
|
name = "nu"
|
|
|
|
|
path = "src/main.rs"
|
2023-02-12 23:22:00 +01:00
|
|
|
bench = false
|
2022-09-29 20:37:48 +02:00
|
|
|
|
2022-10-17 23:45:28 +02:00
|
|
|
# To use a development version of a dependency please use a global override here
|
|
|
|
|
# changing versions in each sub-crate of the workspace is tedious
|
2024-02-12 15:30:41 +01:00
|
|
|
[patch.crates-io]
|
2024-05-28 20:53:51 +02:00
|
|
|
# reedline = { git = "https://github.com/nushell/reedline", branch = "main" }
|
2023-03-13 23:38:18 +01:00
|
|
|
# nu-ansi-term = {git = "https://github.com/nushell/nu-ansi-term.git", branch = "main"}
|
2023-01-05 20:39:54 +01:00
|
|
|
|
|
|
|
|
# Run all benchmarks with `cargo bench`
|
|
|
|
|
# Run individual benchmarks like `cargo bench -- <regex>` e.g. `cargo bench -- parse`
|
|
|
|
|
[[bench]]
|
2023-01-11 02:51:25 +01:00
|
|
|
name = "benchmarks"
|
2024-06-25 20:29:47 +02:00
|
|
|
harness = false
|
