Bump notify from 4.0.17 to 6.0.0 #7
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bumps [notify](https://github.com/notify-rs/notify) from 4.0.17 to 6.0.0. - [Release notes](https://github.com/notify-rs/notify/releases) - [Changelog](https://github.com/notify-rs/notify/blob/main/CHANGELOG.md) - [Commits](notify-rs/notify@4.0.17...notify-6.0.0) --- updated-dependencies: - dependency-name: notify dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
dependencies
Author
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
hustcer
pushed a commit
that referenced
this pull request
Sep 27, 2023
…10430) should close nushell/nushell#10406 # Description when writing a script, with variables you try to `ls` or `open`, you will get a "directory not found" error but the variable won't be expanded and you won't be able to see which one of the variable was the issue... this PR adds this information to the error. # User-Facing Changes let's define a variable ```nushell let does_not_exist = "i_do_not_exist_in_the_current_directory" ``` ### before ```nushell > open $does_not_exist Error: nu::shell::directory_not_found × Directory not found ╭─[entry #7:1:1] 1 │ open $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── ``` ```nushell > ls $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #8:1:1] 1 │ ls $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── ``` ### after ```nushell > open $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #3:1:1] 1 │ open $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist ``` ```nushell > ls $does_not_exist Error: nu:🐚:directory_not_found × Directory not found ╭─[entry #4:1:1] 1 │ ls $does_not_exist · ───────┬─────── · ╰── directory not found ╰──── help: /home/amtoine/documents/repos/github.com/amtoine/nushell/i_do_not_exist_in_the_current_directory does not exist ``` # Tests + Formatting shouldn't harm anything 🤞 # After Submitting
hustcer
pushed a commit
that referenced
this pull request
Oct 2, 2023
should close #10549
# Description
this PR is twofold
- uses `to nuon --raw` in the error messages to make sure #10549 is
solved and makes a difference between `"1"` and `1`
- tries to introduce slightly better errors, i.e. by putting left /
right on new lines => this should hopefully help when the values become
a bit big 😋
# User-Facing Changes
the original issue:
```nushell
> assert equal {one:1 two:2} {one:"1" two:"2"}
Error: × Assertion failed.
╭─[entry #3:1:1]
1 │ assert equal {one:1 two:2} {one:"1" two:"2"}
· ───────────────┬───────────────
· ╰── These are not equal.
Left : '{one: 1, two: 2}'
Right : '{one: "1", two: "2"}'
╰────
```
a sample for all the assertions and their new messages
```nushell
> assert equal {one:1 two:2} {one:"1" two:"2"}
Error: × Assertion failed.
╭─[entry #3:1:1]
1 │ assert equal {one:1 two:2} {one:"1" two:"2"}
· ───────────────┬───────────────
· ╰── These are not equal.
Left : '{one: 1, two: 2}'
Right : '{one: "1", two: "2"}'
╰────
```
```nushell
> assert equal 1 2
Error: × Assertion failed.
╭─[entry #4:1:1]
1 │ assert equal 1 2
· ─┬─
· ╰── These are not equal.
Left : '1'
Right : '2'
╰────
```
```nushell
> assert less 3 1
Error: × Assertion failed.
╭─[entry #6:1:1]
1 │ assert less 3 1
· ─┬─
· ╰── The condition *left < right* is not satisfied.
Left : '3'
Right : '1'
╰────
```
```nushell
> assert less or equal 3 1
Error: × Assertion failed.
╭─[entry #7:1:1]
1 │ assert less or equal 3 1
· ─┬─
· ╰── The condition *left <= right* is not satisfied.
Left : '3'
Right : '1'
╰────
```
```nushell
> assert greater 1 3
Error: × Assertion failed.
╭─[entry #8:1:1]
1 │ assert greater 1 3
· ─┬─
· ╰── The condition *left > right* is not satisfied.
Left : '1'
Right : '3'
╰────
```
```nushell
> assert greater or equal 1 3
Error: × Assertion failed.
╭─[entry #9:1:1]
1 │ assert greater or equal 1 3
· ─┬─
· ╰── The condition *left < right* is not satisfied.
Left : '1'
Right : '3'
╰────
```
```nushell
> assert length [1 2 3] 2
Error: × Assertion failed.
╭─[entry #10:1:1]
1 │ assert length [1 2 3] 2
· ────┬────
· ╰── This does not have the correct length:
value : [1, 2, 3]
length : 3
expected : 2
╰────
```
```nushell
> assert length [1 "2" 3] 2
Error: × Assertion failed.
╭─[entry #11:1:1]
1 │ assert length [1 "2" 3] 2
· ─────┬─────
· ╰── This does not have the correct length:
value : [1, "2", 3]
length : 3
expected : 2
╰────
```
```nushell
> assert str contains "foo" "bar"
Error: × Assertion failed.
╭─[entry #13:1:1]
1 │ assert str contains "foo" "bar"
· ─────┬─────
· ╰── This does not contain '($right)'.
value: "foo"
╰────
```
# Tests + Formatting
# After Submitting
hustcer
pushed a commit
that referenced
this pull request
Oct 10, 2023
Fixes #10644
## the deprecation errors
- using `--pretty` alone` will run the command and give a warning
```nushell
> {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4
Error: × Deprecated option
╭─[entry #7:1:1]
1 │ {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4
· ───┬──
· ╰── `to xml --pretty {int}` is deprecated and will be removed in 0.87.
╰────
help: Please use `--indent {int}` instead.
<note>
<remember>Event</remember>
</note>
```
- using `--pretty` and `--indent` will give the deprecation warning and
throw an error
```nushell
> {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 --indent 4
Error: × Deprecated option
╭─[entry #9:1:1]
1 │ {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 --indent 4
· ───┬──
· ╰── `to xml --pretty {int}` is deprecated and will be removed in 0.87.
╰────
help: Please use `--indent {int}` instead.
Error: nu:🐚:incompatible_parameters
× Incompatible parameters.
╭─[entry #9:1:1]
1 │ {tag: note content : [{tag: remember content : [Event]}]} | to xml --pretty 4 --indent 4
· ┬ ┬
· │ ╰── and --indent
· ╰── Cannot pass --pretty
╰────
```
hustcer
pushed a commit
that referenced
this pull request
Dec 22, 2023
# Description
While #11057 is merged, it's hard to tell the difference between
`--flag: bool` and `--flag`, and it makes user hard to read custom
commands' signature, and hard to use them correctly.
After discussion, I think we can deprecate `--flag: bool` usage, and
encourage using `--flag` instead.
# User-Facing Changes
The following code will raise warning message, but don't stop from
running.
```nushell
❯ def florb [--dry-run: bool, --another-flag] { "aaa" }; florb
Error: × Deprecated: --flag: bool
╭─[entry #7:1:1]
1 │ def florb [--dry-run: bool, --another-flag] { "aaa" }; florb
· ──┬─
· ╰── `--flag: bool` is deprecated. Please use `--flag` instead, more info: https://www.nushell.sh/book/custom_commands.html
╰────
aaa
```
cc @kubouch
# Tests + Formatting
Done
# After Submitting
- [ ] Add more information under
https://www.nushell.sh/book/custom_commands.html to indicate `--dry-run:
bool` is not allowed,
- [ ] remove `: bool` from custom commands between 0.89 and 0.90
---------
Co-authored-by: Antoine Stevan <[email protected]>
hustcer
pushed a commit
that referenced
this pull request
Jun 11, 2024
# Description Fix wrong casting which is related to nushell/nushell#12974 (comment) # User-Facing Changes AS-IS (before fixing) ``` $ "-10000PiB" | into filesize 6.2 EiB <--- Wrong casted value $ "10000PiB" | into filesize -6.2 EiB <--- Wrong casted value ``` TO-BE (after fixing) ``` $ "-10000PiB" | into filesize Error: nu::shell::cant_convert × Can't convert to filesize. ╭─[entry #6:1:1] 1 │ "-10000PiB" | into filesize · ─────┬───── · ╰── can't convert string to filesize ╰──── $ "10000PiB" | into filesize Error: nu:🐚:cant_convert × Can't convert to filesize. ╭─[entry #7:1:1] 1 │ "10000PiB" | into filesize · ─────┬──── · ╰── can't convert string to filesize ╰──── ```
hustcer
pushed a commit
that referenced
this pull request
Feb 7, 2025
# Description
After this pr, nushell is able to raise errors with a backtrace, which
should make users easier to debug. To enable the feature, users need to
set env variable via `$env.NU_BACKTRACE = 1`. But yeah it might not work
perfectly, there are some corner cases which might not be handled.
I think it should close #13379 in another way.
### About the change
The implementation mostly contained with 2 parts:
1. introduce a new `ChainedError` struct as well as a new
`ShellError::ChainedError` variant. If `eval_instruction` returned an
error, it converts the error to `ShellError::ChainedError`.
`ChainedError` struct is responsable to display errors properly. It
needs to handle the following 2 cases:
- if we run a function which runs `error make` internally, it needs to
display the error itself along with caller span.
- if we run a `error make` directly, or some commands directly returns
an error, we just want nushell raise an error about `error make`.
2. Attach caller spans to `ListStream` and `ByteStream`, because they
are lazy streams, and *only* contains the span that runs it
directly(like `^false`, for example), so nushell needs to add all caller
spans to the stream.
For example: in `def a [] { ^false }; def b [] { a; 33 }; b`, when we
run `b`, which runs `a`, which runs `^false`, the `ByteStream` only
contains the span of `^false`, we need to make it contains the span of
`a`, so nushell is able to get all spans if something bad happened.
This behavior is happened after running `Instruction::Call`, if it
returns a `ByteStream` and `ListStream`, it will call `push_caller_span`
method to attach call spans.
# User-Facing Changes
It's better to demostrate how it works by examples, given the following
definition:
```nushell
> $env.NU_BACKTRACE = 1
> def a [x] { if $x == 3 { error make {msg: 'a custom error'}}}
> def a_2 [x] { if $x == 3 { ^false } else { $x } }
> def a_3 [x] { if $x == 3 { [1 2 3] | each {error make {msg: 'a custom error inside list stream'} } } }
> def b [--list-stream --external] {
if $external == true {
# error with non-zero exit code, which is generated from external command.
a_2 1; a_2 3; a_2 2
} else if $list_stream == true {
# error generated by list-stream
a_3 1; a_3 3; a_3 2
} else {
# error generated by command directly
a 1; a 2; a 3
}
}
```
Run `b` directly shows the following error:
<details>
```nushell
Error: chained_error
× oops
╭─[entry #27:1:1]
1 │ b
· ┬
· ╰── error happened when running this
╰────
Error: chained_error
× oops
╭─[entry #26:10:19]
9 │ # error generated by command directly
10 │ a 1; a 2; a 3
· ┬
· ╰── error happened when running this
11 │ }
╰────
Error:
× a custom error
╭─[entry #6:1:26]
1 │ def a [x] { if $x == 3 { error make {msg: 'a custom error'}}}
· ─────┬────
· ╰── originates from here
╰────
```
</details>
Run `b --list-stream` shows the following error
<details>
```nushell
Error: chained_error
× oops
╭─[entry #28:1:1]
1 │ b --list-stream
· ┬
· ╰── error happened when running this
╰────
Error: nu:🐚:eval_block_with_input
× Eval block failed with pipeline input
╭─[entry #26:7:16]
6 │ # error generated by list-stream
7 │ a_3 1; a_3 3; a_3 2
· ─┬─
· ╰── source value
8 │ } else {
╰────
Error: nu:🐚:eval_block_with_input
× Eval block failed with pipeline input
╭─[entry #23:1:29]
1 │ def a_3 [x] { if $x == 3 { [1 2 3] | each {error make {msg: 'a custom error inside list stream'} } } }
· ┬
· ╰── source value
╰────
Error:
× a custom error inside list stream
╭─[entry #23:1:44]
1 │ def a_3 [x] { if $x == 3 { [1 2 3] | each {error make {msg: 'a custom error inside list stream'} } } }
· ─────┬────
· ╰── originates from here
╰────
```
</details>
Run `b --external` shows the following error:
<details>
```nushell
Error: chained_error
× oops
╭─[entry #29:1:1]
1 │ b --external
· ┬
· ╰── error happened when running this
╰────
Error: nu:🐚:eval_block_with_input
× Eval block failed with pipeline input
╭─[entry #26:4:16]
3 │ # error with non-zero exit code, which is generated from external command.
4 │ a_2 1; a_2 3; a_2 2
· ─┬─
· ╰── source value
5 │ } else if $list_stream == true {
╰────
Error: nu:🐚:non_zero_exit_code
× External command had a non-zero exit code
╭─[entry #7:1:29]
1 │ def a_2 [x] { if $x == 3 { ^false } else { $x } }
· ──┬──
· ╰── exited with code 1
╰────
```
</details>
It also added a message to guide the usage of NU_BACKTRACE, see the last
line in the following example:
```shell
ls asdfasd
Error: nu:🐚:io::not_found
× I/O error
╰─▶ × Entity not found
╭─[entry #17:1:4]
1 │ ls asdfasd
· ───┬───
· ╰── Entity not found
╰────
help: The error occurred at '/home/windsoilder/projects/nushell/asdfasd'
set the `NU_BACKTRACE=1` environment variable to display a backtrace.
```
# Tests + Formatting
Added some tests for the behavior.
# After Submitting
hustcer
pushed a commit
that referenced
this pull request
Apr 11, 2025
Issue #12289, can be closed when this is merged
# Description
Currently, the ``into datetime`` command's signature indicates that it
supports input as record, but it was actually not supported.
This PR implements this feature.
# User-Facing Changes
``into datetime``'s signature changed (see comments)
**Happy paths**
Note: I'm in +02:00 timezone.
```nushell
> date now | into record | into datetime
Fri, 4 Apr 2025 18:32:34 +0200 (now)
> {year: 2025, month: 12, day: 6, second: 59} | into datetime | into record
╭─────────────┬────────╮
│ year │ 2025 │
│ month │ 12 │
│ day │ 6 │
│ hour │ 0 │
│ minute │ 0 │
│ second │ 59 │
│ millisecond │ 0 │
│ microsecond │ 0 │
│ nanosecond │ 0 │
│ timezone │ +02:00 │
╰─────────────┴────────╯
> {day: 6, second: 59, timezone: '-06:00'} | into datetime | into record
╭─────────────┬────────╮
│ year │ 2025 │
│ month │ 4 │
│ day │ 6 │
│ hour │ 0 │
│ minute │ 0 │
│ second │ 59 │
│ millisecond │ 0 │
│ microsecond │ 0 │
│ nanosecond │ 0 │
│ timezone │ -06:00 │
╰─────────────┴────────╯
```
**Edge cases**
```nushell
{} | into datetime
Fri, 4 Apr 2025 18:35:19 +0200 (now)
```
**Error paths**
- A key has a wrong type
```nushell
> {month: 12, year: '2023'} | into datetime
Error: nu::shell::only_supports_this_input_type
× Input type not supported.
╭─[entry #8:1:19]
1 │ {month: 12, year: '2023'} | into datetime
· ───┬── ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰────
```
```nushell
> {month: 12, year: 2023, timezone: 100} | into datetime
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #10:1:35]
1 │ {month: 12, year: 2023, timezone: 100} | into datetime
· ─┬─ ──────┬──────
· │ ╰── only string input data is supported
· ╰── input type: int
╰────
```
- Key has the right type but value invalid (e.g. month=13, or day=0)
```nushell
> {month: 13, year: 2023} | into datetime
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #9:1:1]
1 │ {month: 13, year: 2023} | into datetime
· ───────────┬─────────── ──────┬──────
· │ ╰── one of more values are incorrect and do not represent valid date
· ╰── encountered here
╰────
```
```nushell
> {hour: 1, minute: 1, second: 70} | into datetime
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #3:1:1]
1 │ {hour: 1, minute: 1, second: 70} | into datetime
· ────────────────┬─────────────── ──────┬──────
· │ ╰── one of more values are incorrect and do not represent valid time
· ╰── encountered here
╰────
```
- Timezone has right type but is invalid
```nushell
> {month: 12, year: 2023, timezone: "+100:00"} | into datetime
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #11:1:35]
1 │ {month: 12, year: 2023, timezone: "+100:00"} | into datetime
· ────┬──── ──────┬──────
· │ ╰── encountered here
· ╰── invalid timezone
╰────
```
- Record contains an invalid key
```nushell
> {month: 12, year: 2023, unknown: 1} | into datetime
Error: nu:🐚:unsupported_input
× Unsupported input
╭─[entry #12:1:1]
1 │ {month: 12, year: 2023, unknown: 1} | into datetime
· ─────────────────┬───────────────── ──────┬──────
· │ ╰── Column 'unknown' is not valid for a structured datetime. Allowed
columns are: year, month, day, hour, minute, second, millisecond,
microsecond, nanosecond, timezone
· ╰── value originates from here
╰────
```
- If several issues are present, the user can get the error msg for only
one, though
```nushell
> {month: 20, year: '2023'} | into datetime
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #7:1:19]
1 │ {month: 20, year: '2023'} | into datetime
· ───┬── ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰
```
# Tests + Formatting
Tests added
Fmt + clippy OK
# After Submitting
Maybe indicate that in the release notes
I added an example in the command, so the documentation will be
automatically updated.
hustcer
pushed a commit
that referenced
this pull request
Apr 20, 2025
Closes #15543
# Description
1. Simplify code in ``datetime.rs`` based on a suggestion in my last PR
on "datetime from record"
1. Make ``into duration`` work with durations inside a record, provided
as a cell path
1. Make ``into duration`` work with durations as record
# User-Facing Changes
```nushell
# Happy paths
~> {d: '1hr'} | into duration d
╭───┬─────╮
│ d │ 1hr │
╰───┴─────╯
~> {week: 10, day: 2, sign: '+'} | into duration
10wk 2day
# Error paths and invalid usage
~> {week: 10, day: 2, sign: 'x'} | into duration
Error: nu::shell::incorrect_value
× Incorrect value.
╭─[entry #4:1:26]
1 │ {week: 10, day: 2, sign: 'x'} | into duration
· ─┬─ ──────┬──────
· │ ╰── encountered here
· ╰── Invalid sign. Allowed signs are +, -
╰────
~> {week: 10, day: -2, sign: '+'} | into duration
Error: nu:🐚:incorrect_value
× Incorrect value.
╭─[entry #5:1:17]
1 │ {week: 10, day: -2, sign: '+'} | into duration
· ─┬ ──────┬──────
· │ ╰── encountered here
· ╰── number should be positive
╰────
~> {week: 10, day: '2', sign: '+'} | into duration
Error: nu:🐚:only_supports_this_input_type
× Input type not supported.
╭─[entry #6:1:17]
1 │ {week: 10, day: '2', sign: '+'} | into duration
· ─┬─ ──────┬──────
· │ ╰── only int input data is supported
· ╰── input type: string
╰────
~> {week: 10, unknown: 1} | into duration
Error: nu:🐚:unsupported_input
× Unsupported input
╭─[entry #7:1:1]
1 │ {week: 10, unknown: 1} | into duration
· ───────────┬────────── ──────┬──────
· │ ╰── Column 'unknown' is not valid for a structured duration. Allowed columns are: week, day, hour, minute, second, millisecond, microsecond, nanosecond, sign
· ╰── value originates from here
╰────
~> {week: 10, day: 2, sign: '+'} | into duration --unit sec
Error: nu:🐚:incompatible_parameters
× Incompatible parameters.
╭─[entry #2:1:33]
1 │ {week: 10, day: 2, sign: '+'} | into duration --unit sec
· ──────┬────── ─────┬────
· │ ╰── the units should be included in the record
· ╰── got a record as input
╰────
```
# Tests + Formatting
- Add examples and integration tests for ``into duration``
- Add one test for ``into duration``
# After Submitting
If this is merged in time, I'll update my PR on the "datetime handling
highlights" for the release notes.
hustcer
pushed a commit
that referenced
this pull request
Apr 26, 2025
…tor (#15623)
# Description
Fixes: #15510
I think it's introduced by #14653, which changes `and/or` to `match`
expression.
After looking into `compile_match`, it's important to collect the value
before matching this.
```rust
// Important to collect it first
builder.push(Instruction::Collect { src_dst: match_reg }.into_spanned(match_expr.span))?;
```
This pr is going to apply the logic while compiling `and/or` operation.
# User-Facing Changes
The following will raise a reasonable error:
```nushell
> (nu --testbin cococo false) and true
Error: nu::shell::operator_unsupported_type
× The 'and' operator does not work on values of type 'string'.
╭─[entry #7:1:2]
1 │ (nu --testbin cococo false) and true
· ─┬ ─┬─
· │ ╰── does not support 'string'
· ╰── string
╰────
```
# Tests + Formatting
Added 1 test.
# After Submitting
Maybe need to update doc
nushell/nushell.github.io#1876
---------
Co-authored-by: Stefan Holderbach <[email protected]>
hustcer
pushed a commit
that referenced
this pull request
May 17, 2025
Closes #14469 # Description - ~~Implement the ``--unit`` conversion in "into int" command~~ - New ``ShellError::InvalidUnit`` unit if users enter wrong units - Made ``ShellError::CantConvertToDuration`` more generic: became ``CantConvertToUnit`` - Tried to improve the way we parse units and get the supported units. It's not complete, though, I will continue this refactoring in another PR. But I already did some small refactorings in the "format duration" and "format filesize" commands - Add tests for "format filesize" and "format duration" # User-Facing Changes ```nu ~> 1MB | format filesize sec Error: nu::shell::invalid_unit × Invalid unit ╭─[entry #7:1:23] 1 │ 1MB | format filesize sec · ─┬─ · ╰── encountered here ╰──── help: Supported units are: B, kB, MB, GB, TB, PB, EB, KiB, MiB, GiB, TiB, PiB, EiB ```
hustcer
pushed a commit
that referenced
this pull request
Jul 1, 2025
# Description
This PR makes the span of a pipeline accessible through `metadata`,
meaning it's possible to get the span of a pipeline without collecting
it.
Examples:
```nushell
ls | metadata
# => ╭────────┬────────────────────╮
# => │ │ ╭───────┬────────╮ │
# => │ span │ │ start │ 170218 │ │
# => │ │ │ end │ 170220 │ │
# => │ │ ╰───────┴────────╯ │
# => │ source │ ls │
# => ╰────────┴────────────────────╯
```
```nushell
ls | metadata access {|meta|
error make {msg: "error", label: {text: "here", span: $meta.span}}
}
# => Error: × error
# => ╭─[entry #7:1:1]
# => 1 │ ls | metadata access {|meta|
# => · ─┬
# => · ╰── here
# => 2 │ error make {msg: "error", label: {text: "here", span: $meta.span}}
# => ╰────
```
Here's an example that wouldn't be possible before, since you would have
to use `metadata $in` to get the span, collecting the (infinite) stream
```nushell
generate {|x=0| {out: 0, next: 0} } | metadata access {|meta|
# do whatever with stream
error make {msg: "error", label: {text: "here", span: $meta.span}}
}
# => Error: × error
# => ╭─[entry #16:1:1]
# => 1 │ generate {|x=0| {out: 0, next: 0} } | metadata access {|meta|
# => · ────┬───
# => · ╰── here
# => 2 │ # do whatever with stream
# => ╰────
```
I haven't done the tests or anything yet since I'm not sure how we feel
about having this as part of the normal metadata, rather than a new
command like `metadata span` or something. We could also have a
`metadata access` like functionality for that with an optional closure
argument potentially.
# User-Facing Changes
* The span of a pipeline is now available through `metadata` and
`metadata access` without collecting a stream.
# Tests + Formatting
TODO
# After Submitting
N/A
hustcer
pushed a commit
that referenced
this pull request
Oct 8, 2025
This PR adds the `toolkit run pr` and `toolkit download pr` commands to `toolkit`. This is a more fleshed out version of the snippet shared in #16633, with robust error handling and cross-platform unzip support. When using `toolkit run pr`, the script will also check if the most recent binary for that PR has already been downloaded, and if so it will run that instead. I tried to make the error reporting as good as a built-in command to see how difficult that would be, and with use of the `--head: oneof<>` trick, it turned out pretty good. With access to the call span, the workflow is very similar to when writing a built-in command. I also used a `Spanned`-like record, which helped as well. ```nushell toolkit run pr 16740 # => Error: nu::shell::error # => # => × Command not found # => ╭─[entry #4:1:26] # => 1 │ overlay use -pr toolkit; toolkit run pr 16740 # => · ───────┬────── # => · ╰── requires `gh` # => ╰──── # => help: Please install the `gh` commandline tool ``` <details> <summary>More error reporting notes</summary> In an earlier version of the script, `run pr` called `download pr` directly. I ended up changing the way this worked so that `run pr` could use the workflow_id. Here's a couple snippets I thought were neat from this older version. **Passing span via `--head`:** ```nushell def download [--head: oneof<>] { let span = $head | default (metadata $head).span error make {msg: "a", label: {text: here, span: $span}} } def run [--head: oneof<>] { let span = (metadata $head).span download --head=$span } download # => Error: nu:🐚:error # => # => × a # => ╭─[entry #6:1:1] # => 1 │ download # => · ────┬─── # => · ╰── here # => ╰──── run # => Error: nu:🐚:error # => # => × a # => ╭─[entry #7:1:1] # => 1 │ run # => · ─┬─ # => · ╰── here # => ╰──── ``` **Using "spanned" number as CLI parameter and as internal caller parameter** ```nushell def download [number: oneof<int, record<item: int, span: record>>] { let number = match $number { {item: $_, span: $_} => $number, $val => {item: $number, span: (metadata $number).span} } error make {msg: "a", label: {text: here, span: $number.span}} } def run [number: int] { let number = {item: $number, span: (metadata $number).span} download $number } download 123 # => Error: nu:🐚:error # => # => × a # => ╭─[entry #9:1:10] # => 1 │ download 123 # => · ─┬─ # => · ╰── here # => ╰──── run 123 # => Error: nu:🐚:error # => # => × a # => ╭─[entry #10:1:5] # => 1 │ run 123 # => · ─┬─ # => · ╰── here # => ╰──── ``` </details> ## Release notes summary - What our users need to know The toolkit in the Nushell repository can now download and run PRs by downloading artifacts from CI runs. It can be run like this: ```nushell use toolkit toolkit run pr <number> ```
hustcer
pushed a commit
that referenced
this pull request
Dec 19, 2025
## User-facing Changes
* New arguments! (`error make "hello"`)
* New parts for `error_struct`! (`error make {inner: [] labels: []
...}`)
* Pipeline inputs for chained errors! (`try {error make foo} catch
{error make bar}`)
* Pipeline inputs for normal errors! (`"help" | error make`)
* External errors! (`error make {src: {path: $nu.cofig-path} ...}`)
* Backwards compatibility!
### Arguments and Inputs
The main changes are in how the arguments are passed. Everything is
still backwards compatible with the old `error make` commands, there's
just a nice extra layer we get from the pipeline and a few new args
(that were already added in #17037). There are some new ways to
(hopefully intentionally) cause an error, such as using a naked `error
make`, pipelines from records and simple string input!
#### Inputs
Because `error make` will just make an error anyway, it can technically
take any input to make an error, but only properly formatted record
input will create a chain. the `x | f $in` pattern can be used for
string input, if that is more comfortable.
#### With no arguments
This is a completely new way to do this, with no arguments the `error
make` invocation is highlighted, along with a simple `originates from
here` message. This makes normal errors very easy to create without any
special message setup.
```
> error make
Error: nu::shell::error
× originates from here
╭─[entry #4:1:1]
1 │ error make
· ──────────
╰────
```
#### Create a single argument
* With pipeline input: `{msg: foo} | error make`
* With an argument: `error make {msg: foo}`
* With a string argument: `error make foo`
```
Error: nu:🐚:error
× foo
╭─[entry #2:1:12]
1 │ error make {msg: foo}
· ──────────
╰────
```
#### Chaining errors together
These will automatically create a chain of errors, placing the pipeline
as an `inner` to the argument. This can very easily be used to get a bit
more detail in a try loop using the naked `error make`:
```
Error: nu:🐚:error
× originates from here
╭─[source:1:31]
1 │ try {error make "foo"} catch {error make}
· ──────────
╰────
Error: nu:🐚:error
× foo
╭─[source:1:6]
1 │ try {error make "foo"} catch {error make}
· ──────────
╰────
```
Or with more complex errors:
* With both, combining the errors: `{msg: foo} | error make bar`
* With the raw error from try: `try {error make foo} catch {error make
bar}`
Both are equivalent to:
* `error make {msg: bar inner: [{msg: foo}]}`
```
Error: nu:🐚:error
× bar
╭─[entry #1:1:29]
1 │ try {error make foo} catch {error make bar}
· ──────────
╰────
Error: nu:🐚:error
× foo
╭─[entry #1:1:6]
1 │ try {error make foo} catch {error make bar}
· ──────────
╰────
```
### Labels
As is noticeable in the examples above, simple errors no longer use an
extra line for the label. If no label is present, `error make` will
place a bar under the span of itself or the argument to `error make`.
Labels have also gotten a bit of a rewrite, but they're pretty much the
same as those in #17037, except for `label`, which is now only a single
label (not `oneof<list, label>`).
#### Simple Labels
`label.text` and `labels.*.text` is no longer required for a span to
show up, an empty text will simply underline. This example can either
use `label: $record` or be written as `labels: [$record]`:
```
> def f [x] {
error make {msg: here label: {span: (metadata $x).span}}
}
f abcd
Error: nu::shell::error
× here
╭─[entry #7:4:3]
3 │ }
4 │ f abcd
· ────
╰────
```
#### Multiple labels
Any number of labels can be added in the `labels` column, allowing for
more detailed error messages, especially for functions:
```
> def f [x y z] {
error make {msg: here labels: [
{text: "there" span: (metadata $x).span}
{text: "everywhere" span: (metadata $y).span}
{text: "somewhere" span: (metadata $z).span}
]
}
}
f abcd [x y z] {d: a}
Error: nu:🐚:error
× here
╭─[entry #11:9:3]
8 │ }
9 │ f abcd [x y z] {d: a}
· ──┬─ ───┬─── ───┬──
· │ │ ╰── somewhere
· │ ╰── everywhere
· ╰── there
╰────
```
#### External sources
There is a `ShellError::OutsideSpannedLabeledError` that can be used to
refer to external sources, not just the internal nushell spanns. This
has been expanded to allow the multi-label stuff to work using the new
`src` column:
```
> "foo\nbar\nbaz" | save -f /tmp/foo.bar
error make {
msg: 'error here'
src: {path: /tmp/foo.bar}
labels: [
{text: "this" span: {start: 4 end: 7}}
]
}
Error: nu:🐚:outside
× error here
╭─[/tmp/foo.bar:2:1]
1 │ foo
2 │ bar
· ─┬─
· ╰── this
3 │ baz
╰────
```
### Errors That Can't be Caught
These will not work since `try` will never get parsed:
- `try {1 + ""} catch {error make badmath}`
- (TODO: Add more examples)
## Internal Changes
Most of the parsing from an error record to an actual error is now moved
into `nu-protocol`, using `FromValue` to turn it into a useful internal
type.
### `nu-protocol::LabeledError`
This struct has a few changes, the main one being the type of
`LabeledError.inner`. It is now a `ShellError`, not another
`LabeledError`. It should be trivial to do a `.into()` for things that
already use `LabeledError.with_inner(x)`.
### `nu-protocol::ShellError::into_value`
I renamed the old `into_value` to `into_full_value` to better say what
it is, since it doesn't just do the `IntoValue::into_value` method, it
also requires some context to create the `Value`. Now `ShellError` has
an `IntoValue` implementation matching other types.
### `nu-protocol::ShellError::{OutsideSource, OutsideSourceNoUrl}`
Miette's derived types don't have a nice way to maybe include a url, so
there are now two types! These allow using multiple labels on outside
sources. They are used internally for the new `{src: {}}` part of the
`error_struct`, and they look a lot more like the `LabeledError`, but
without the need for a separate type and all the fun `impl`s that would
require for the `Diagnostic::source_code` method.
### Misc
* Spelling fix: `into_chainned` => `into_chained`
## Current bugs:
- [x] `OutsideSpannedLabeledError`
The inner most error of `try {']' from nuon} catch {error make}` will
reference `span: {start: 0, end: 1}`, which in `']' from nuon` will
point to the `]` character, but when it does this in `error make` as an
input it will point to the very first character (probably the `n` in
`nu`).
## Release notes summary - What our users need to know
### New `error make` functionality!
* New arguments! (`error make "hello"`)
* New parts for `error_struct`! (`error make {inner: [] labels: []
...}`)
* Pipeline inputs for chained errors! (`try {error make foo} catch
{error make bar}`)
* Pipeline inputs for normal errors! (`"help" | error make`)
* External errors! (`error make {src: {path: $nu.cofig-path} ...}`)
* Backwards compatibility!
## Tasks after submitting
<!-- Remove any tasks which aren't relevant for your PR, or add your own
-->
- [ ] Update the
[documentation](https://github.com/nushell/nushell.github.io)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps notify from 4.0.17 to 6.0.0.
Release notes
Sourced from notify's releases.
Changelog
Sourced from notify's changelog.
... (truncated)
Commits
b6e4094prepare v6 and fix 5.2.07b89553Raise MSRV to 1.60af9feefRename debouncer-refined to debouncer-full679fc4aUse path to link to local dependencies1d88f6dRevert "Use workspace dependencies"b225bfeRevert "Update dependencies"4716930cargo clippyb2b05eecargo fmt4fc2a10Improve docsa2f5666Rename file-id's inode property to fileDependabot 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 commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill 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 versionwill 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 dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)