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
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
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] <support@github.com>
dependabot
bot
added
dependencies
|
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 <44101798+amtoine@users.noreply.github.com>
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 <sholderbach@users.noreply.github.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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)