Commit Graph

6797 Commits

Author SHA1 Message Date
zc he
24dba9dc53
fix(lsp): regression of semantic tokens of module-prefixed commands (#15603)
# Description

Fixes a regression caused by #15567, where I made the space detection in
command names switched from `get_span_content` to `get_decl().name()`,
which is slightly faster but it won't work in some cases:

e.g.
```nushell
use std/assert
assert equal
```

Reverted in this PR.

# User-Facing Changes

None

# Tests + Formatting

Refined

# After Submitting
2025-04-19 06:02:49 -05:00
pyz4
a2dc3e3b33
feat(polars): enable as_date and as_datetime to handle expressions as inputs (#15590)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR is a follow-up to the previous PR #15557 and part of a wider
campaign to enable certain polars commands that only operated on the
entire dataframe to also operate on expressions. Here, we enable two
commands `polars as-date` and `polars as-datetime` to receive
expressions as inputs so that they may be used on specific columns in a
dataframe with multiple columns of different types. See examples below.

```nushell
> [[a b]; ["2025-04-01" 1] ["2025-04-02" 2] ["2025-04-03" 3]] | polars into-df | polars select (polars col a | polars as-date %Y-%m-%d) b | polars collect
╭───┬───────────────────────┬───╮
│ # │           a           │ b │
├───┼───────────────────────┼───┤
│ 0 │ 04/01/2025 12:00:00AM │ 1 │
│ 1 │ 04/02/2025 12:00:00AM │ 2 │
│ 2 │ 04/03/2025 12:00:00AM │ 3 │
╰───┴───────────────────────┴───╯

> seq date -b 2025-04-01 --periods 4 --increment 25min -o "%Y-%m-%d %H:%M:%S" | polars into-df | polars select (polars col 0 | polars as-datetime "%Y-%m-%d %H:%M:%S") | polars collect
╭───┬───────────────────────╮
│ # │           0           │
├───┼───────────────────────┤
│ 0 │ 04/01/2025 12:00:00AM │
│ 1 │ 04/01/2025 12:25:00AM │
│ 2 │ 04/01/2025 12:50:00AM │
│ 3 │ 04/01/2025 01:15:00AM │
╰───┴───────────────────────╯

``` 

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have the additional option to use `polars
as-date` and `polars as-datetime` in expressions that operate on
specific columns.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Examples have been added to `polars as-date` and `polars as-datetime`.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-18 13:50:36 -07:00
pyz4
95998bdd53
fix(custom_value) + fix(polars): map // operator to FloorDivide for custom values and in polars (#15599)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR fixes an issue where, for custom values, the `//` operator was
incorrectly mapped to `Math::Divide` instead of `Math::FloorDivide`.
This PR also fixes the same mis-mapping in the `polars` plugin.

```nushell
> [[a b c]; [x 1 1.1] [y 2 2.2] [z 3 3.3]] | polars into-df | polars select {div: ((polars col c) / (polars col b)), floor_div: ((polars col c) // (polars col b))} | polars collect
╭───┬───────┬───────────╮
│ # │  div  │ floor_div │
├───┼───────┼───────────┤
│ 0 │ 1.100 │     1.000 │
│ 1 │ 1.100 │     1.000 │
│ 2 │ 1.100 │     1.000 │
╰───┴───────┴───────────╯
```

**Note:** the number of line changes in this PR is inflated because of
auto-formatting in `nu_plugin_polars/Cargo.toml`. Substantively, I've
only added the `round_series` feature to the polars dependency list.

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Breaking change: users who expected the operator `//` to function the
same as `/` for custom values will not get the expected result.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
No tests were yet added, but let me know if we should put something into
one of the polars examples.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-18 13:49:33 -07:00
pyz4
bd5de023a1
feat(polars): add pow (**) operator for polars expressions (#15598)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR adds the exponent operator ("**") to polars expressions.

```nushell
  > [[a b]; [6 2] [4 2] [2 2]] | polars into-df | polars select a b {c: ((polars col a) ** 2)}
  ╭───┬───┬───┬────╮
  │ # │ a │ b │ c  │
  ├───┼───┼───┼────┤
  │ 0 │ 6 │ 2 │ 36 │
  │ 1 │ 4 │ 2 │ 16 │
  │ 2 │ 2 │ 2 │  4 │
  ╰───┴───┴───┴────╯
```

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users are enabled to use the `**` operator in
polars expressions.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
An example in `polars select` was modified to showcase the `**`
operator.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-18 13:48:59 -07:00
Darren Schroeder
38e761493d
add --raw-value option to debug command (#15581)
# Description

This adds a new option `--raw-value`/`-v` to the `debug` command to
allow you to only get the debug string part of the nushell value.
Because, sometimes you don't need the span or nushell datatype and you
just want the val part.

You can see the difference between `debug -r` and `debug -v` here.

![image](https://github.com/user-attachments/assets/ac16cdf0-2ec8-4f61-a2c4-81341f8d363b)

It should work on all datatypes except Value::Error and Value::Closure.

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-17 12:12:07 -05:00
Julian Amarilla
7fcebf37ec
Fix #15440 default --empty fails at empty streams (#15562)
Fixes #15440 

# Description
Wraps ListStream stream type from `impl Iterator` to `Peekable<impl
Iterator>`, this allows checking for empty streams and treating them as
empty values
 
Example:
```
# previously
$ glob ? | default -e void
> # empty list

$ echo '' | default -e void
> void

####################

# now
$ glob ? | default -e void
> void

$ echo '' | default -e void
> void
```

# User-Facing Changes

empty list streams will behave as `nothing` values when testing for
emptiness

# Tests + Formatting

- Add 2 tests
- clippy OK
- fmt OK

# After Submitting
2025-04-17 16:57:25 +02:00
pyz4
0e9927ea4d
polars: expand polars col to handle multiple columns and by types (#15570)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR seeks to expand `polars col` functionality to allow selecting
multiple columns and columns by type, which is particularly useful when
piping to subsequent expressions that should be applied to each column
selected (e.g., `polars col int --type | polars sum` as a shorthand for
`[(polars col a | polars sum), (polars col b | polars sum)]`). See
examples below.

```nushell
#  Select multiple columns (cannot be used with asterisk wildcard)
  > [[a b c]; [x 1 1.1] [y 2 2.2] [z 3 3.3]] | polars into-df 
          | polars select (polars col b c | polars sum) | polars collect
  ╭───┬───┬──────╮
  │ # │ b │  c   │
  ├───┼───┼──────┤
  │ 0 │ 6 │ 6.60 │
  ╰───┴───┴──────╯

#  Select multiple columns by types (cannot be used with asterisk wildcard)
  > [[a b c]; [x o 1.1] [y p 2.2] [z q 3.3]] | polars into-df 
           | polars select (polars col str f64 --type | polars max) | polars collect
  ╭───┬───┬───┬──────╮
  │ # │ a │ b │  c   │
  ├───┼───┼───┼──────┤
  │ 0 │ z │ q │ 3.30 │
  ╰───┴───┴───┴──────╯
```

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have the additional capability to select
multiple columns in `polars col`.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Examples have been added to `polars col`.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-16 14:30:49 -07:00
Piepmatz
d273ce89df
Add --plugins flag to nu-std/testing.nu (#15552)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
In this PR I added the flag `--plugins` to the `testing.nu` file inside
of `crates/nu-std`. This allows running tests with active plugins. While
I did not use it here in this repo, it allows testing in
[nushell/plugin-examples](https://github.com/nushell/plugin-examples)
with plugins.

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
None, just the additional flag.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

(nothing broke \o/)

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-16 23:20:04 +02:00
pyz4
2dc5c19b71
feat(polars): loosen constraints on accepted expressions in polars group-by (#15583)
# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR lifts the constraint that expressions in the `polars group-by`
command must be limited only to the type `Expr::Column` rather than most
`Expr` types, which is what the underlying polars crate allows. This
change enables more complex expressions to group by.

In the example below, we group by even or odd days of column `a`. While
we can reach the same result by creating and grouping by a new column in
two separate steps, integrating these steps in a single group-by allows
for better delegation to the polars optimizer.

```nushell
#  Group by an expression and perform an aggregation
  > [[a b]; [2025-04-01 1] [2025-04-02 2] [2025-04-03 3] [2025-04-04 4]]
    | polars into-lazy
    | polars group-by (polars col a | polars get-day | $in mod 2)
    | polars agg [
        (polars col b | polars min | polars as "b_min")
        (polars col b | polars max | polars as "b_max")
        (polars col b | polars sum | polars as "b_sum")
     ]
    | polars collect
    | polars sort-by a
  ╭───┬───┬───────┬───────┬───────╮
  │ # │ a │ b_min │ b_max │ b_sum │
  ├───┼───┼───────┼───────┼───────┤
  │ 0 │ 0 │     2 │     4 │     6 │
  │ 1 │ 1 │     1 │     3 │     4 │
  ╰───┴───┴───────┴───────┴───────╯
```  

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. The user is empowered to use more complex
expressions in `polars group-by`

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
An example is added to `polars group-by`.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-16 14:18:48 -07:00
pyz4
669b44ad7d
feat(polars): add polars truncate for rounding datetimes (#15582)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR directly ports the polars function `polars.Expr.dt.truncate`
(https://docs.pola.rs/api/python/stable/reference/expressions/api/polars.Expr.dt.truncate.html),
which rounds a datetime to an arbitrarily specified period length. This
function is particularly useful when rounding to variable period lengths
such as months or quarters. See below for examples.

```nushell
#  Truncate a series of dates by period length
  > seq date -b 2025-01-01 --periods 4 --increment 6wk -o "%Y-%m-%d %H:%M:%S" | polars into-df | polars as-datetime "%F %H:%M:%S" --naive | polars select datetime (polars col datetime | polars truncate 5d37m | polars as truncated) | polars collect
  ╭───┬───────────────────────┬───────────────────────╮
  │ # │       datetime        │       truncated       │
  ├───┼───────────────────────┼───────────────────────┤
  │ 0 │ 01/01/2025 12:00:00AM │ 12/30/2024 04:49:00PM │
  │ 1 │ 02/12/2025 12:00:00AM │ 02/08/2025 09:45:00PM │
  │ 2 │ 03/26/2025 12:00:00AM │ 03/21/2025 02:41:00AM │
  │ 3 │ 05/07/2025 12:00:00AM │ 05/05/2025 08:14:00AM │
  ╰───┴───────────────────────┴───────────────────────╯

#  Truncate based on period length measured in quarters and months
> seq date -b 2025-01-01 --periods 4 --increment 6wk -o "%Y-%m-%d %H:%M:%S" | polars into-df | polars as-datetime "%F %H:%M:%S" --naive | polars select datetime (polars col datetime | polars truncate 1q5mo | polars as truncated) | polars collect
╭───┬───────────────────────┬───────────────────────╮
│ # │       datetime        │       truncated       │
├───┼───────────────────────┼───────────────────────┤
│ 0 │ 01/01/2025 12:00:00AM │ 09/01/2024 12:00:00AM │
│ 1 │ 02/12/2025 12:00:00AM │ 09/01/2024 12:00:00AM │
│ 2 │ 03/26/2025 12:00:00AM │ 09/01/2024 12:00:00AM │
│ 3 │ 05/07/2025 12:00:00AM │ 05/01/2025 12:00:00AM │
╰───┴───────────────────────┴───────────────────────╯

```

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. This PR introduces a new command `polars truncate`

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Example test was added.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-16 14:17:49 -07:00
dependabot[bot]
9a5c4d36be
build(deps): bump data-encoding from 2.8.0 to 2.9.0 (#15580)
Bumps [data-encoding](https://github.com/ia0/data-encoding) from 2.8.0
to 2.9.0.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4fce77c46b"><code>4fce77c</code></a>
Release 2.9.0 (<a
href="https://redirect.github.com/ia0/data-encoding/issues/138">#138</a>)</li>
<li><a
href="d81616352a"><code>d816163</code></a>
Add encode_mut_str to guarantee UTF-8 for safe callers (<a
href="https://redirect.github.com/ia0/data-encoding/issues/137">#137</a>)</li>
<li><a
href="ec53217669"><code>ec53217</code></a>
Update doc badge in README.md (<a
href="https://redirect.github.com/ia0/data-encoding/issues/135">#135</a>)</li>
<li>See full diff in <a
href="https://github.com/ia0/data-encoding/compare/v2.8.0...v2.9.0">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=data-encoding&package-manager=cargo&previous-version=2.8.0&new-version=2.9.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)


</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2025-04-16 22:14:36 +08:00
zc he
cd4560e97a
fix(lsp): a panic caused by completion with decl_id out of range (#15576)
Fixes a bug caused by #15536 
Sorry about that, @fdncred 

# Description

I've made the panic reproducible in the test case.

TLDR: completer will sometimes return new decl_ids outside of the range
of the engine_state passed in.

# User-Facing Changes

bug fix

# Tests + Formatting

+1

# After Submitting
2025-04-16 06:43:21 -05:00
zc he
24cc2f9d87
fix(completion): quoted cell path completion (#15546)
Closes #15525 

# Description

# User-Facing Changes

bug fix

# Tests + Formatting

+1

# After Submitting
2025-04-16 01:26:45 -04:00
Jack Wright
8f81812ef9
fix cannot find issue when performing collect on an eager dataframe (#15577)
# Description
Performing a `polars collect` on an eager dataframe should be a no-op
operation. However, when used with a pipeline and not saving to a value
a cache error occurs. This addresses that cache error.
2025-04-15 14:25:11 -05:00
Mussar
2229370b13
replace repeat().take() with repeat_n() (#15575)
# Description

This updates `string_expand()` in nu-table's util.rs to use the
`std::iter` library's `repeat_n()` function, which was suggested as a
more readable version of the existing `repeat().take()` implementation.

# User-Facing Changes
 
Should have no user facing changes.

# Tests + Formatting

All green circles!
```
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib
```
2025-04-15 23:29:32 +08:00
pyz4
a33650a69e
fix(polars): cast as date now returns Date type instead of Datetime<ns> (#15574)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR fixes the bug where various commands that cast a column as a
`date` type would return `datetime<ns>` rather than the intended type
`date`. Affected commands include `polars into-df --schema`, `polars
into-lazy --schema`, `polars as-date`, and `polars cast date`.

This bug derives from the fact that Nushell uses the `date` type to
denote a datetime type whereas polars differentiates between `Date` and
`Datetime` types. By default, this PR retains the behavior that a
Nushell `date` type will be mapped to a polars `Datetime<ns>` unless
otherwise specified.

```nushell
#  Current (erroneous) implementation
> [[a]; [2025-03-20]] | polars into-df --schema {a: "date"} | polars schema
╭───┬──────────────╮
│ a │ datetime<ns> │
╰───┴──────────────╯

#  Fixed implementation
> [[a]; [2025-03-20]] | polars into-df --schema {a: "date"} | polars schema
╭───┬──────╮
│ a │ date │
╰───┴──────╯

#  Fixed implementation: by default, Nushell dates map to datetime<ns>
> [[a]; [2025-03-20]] | polars into-df | polars schema
╭───┬───────────────────╮
│ a │ datetime<ns, UTC> │
╰───┴───────────────────╯
```

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Soft breaking change: users previously who wanted to cast a date column
to type `date` can now expect the output to be type `date` instead of
`datetime<ns>`.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Example test added to `polars as-date` command.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-15 08:20:54 -07:00
zc he
56d7e4bb89
refactor(completion, lsp): include decl_id in suggetion_kind for later usage (#15536)
# Description

Should be more performant, calling for `find_decl` by name for all
entries is generally a heavy op.

# User-Facing Changes

NA

# Tests + Formatting

# After Submitting
2025-04-15 07:24:56 -05:00
zc he
e5f589ccdd
refactor(lsp): flat_map with mutable accumulator (#15567)
# Description

Mainly performance improvement of lsp operations involving flat_map on
AST nodes.
Previous flat_map traversing is functional, which is a nice property to
have, but the heavy cost of vector collection on each tree node makes it
undesirable.

This PR mitigates the problem with a mutable accumulator.

# User-Facing Changes

Should be none.

# Tests + Formatting

# After Submitting
2025-04-15 07:21:23 -05:00
Renan Ribeiro
8c4d3eaa7e
config commands now add frozen jobs to job table (#15556)
# Description

`config nu/env` used to ignore the frozen wait job status response and
did not add processes to the job table when they were frozen.

This PR refactors the PostWaitCallback used in run_external and allows
frozen processes spawned by `config_.rs` to be added to the job table.

Closes #15389



# User-Facing Changes

`config nu` now respects the job freezing semantics.

# Tests + Formatting
This behavior can be verified by running `config nu` or `config env`,
hitting Ctrl-Z, and then running `job list`.
2025-04-15 06:36:08 -05:00
Jack Wright
89322f59f2
Fix output type of polars schema (#15572)
# Description
Output type of `polars schema` signature output type is of dataframe. It
should be of type record.

# User-Facing Changes
- `polars schema` - how has an output type of record
2025-04-15 06:27:31 -05:00
pyz4
4e307480e4
polars: extend NuExpression::extract_exprs to handle records (#15553)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR seeks to simplify the syntax for commands that handle a list of
expressions (e.g., `select`, `with-column`, and `agg`) by enabling the
user to replace a list of expressions each aliased with `polars as` to a
single record where the key is the alias for the value. See below for
examples in several contexts.

```nushell
#  Select a column from a dataframe using a record
  > [[a b]; [6 2] [4 2] [2 2]] | polars into-df | polars select {c: ((polars col a) * 2)}
  ╭───┬────╮
  │ # │ c  │
  ├───┼────┤
  │ 0 │ 12 │
  │ 1 │  8 │
  │ 2 │  4 │
  ╰───┴────╯

#  Select a column from a dataframe using a mix of expressions and record of expressions
  > [[a b]; [6 2] [4 2] [2 2]] | polars into-df | polars select a b {c: ((polars col a) * 2)}
  ╭───┬───┬───┬────╮
  │ # │ a │ b │ c  │
  ├───┼───┼───┼────┤
  │ 0 │ 6 │ 2 │ 12 │
  │ 1 │ 4 │ 2 │  8 │
  │ 2 │ 2 │ 2 │  4 │
  ╰───┴───┴───┴────╯

#  Add series to the dataframe using a record
  > [[a b]; [1 2] [3 4]]
    | polars into-lazy
    | polars with-column {
        c: ((polars col a) * 2)
        d: ((polars col a) * 3)
      }
    | polars collect
  ╭───┬───┬───┬───┬───╮
  │ # │ a │ b │ c │ d │
  ├───┼───┼───┼───┼───┤
  │ 0 │ 1 │ 2 │ 2 │ 3 │
  │ 1 │ 3 │ 4 │ 6 │ 9 │
  ╰───┴───┴───┴───┴───╯

#  Group by and perform an aggregation using a record
  > [[a b]; [1 2] [1 4] [2 6] [2 4]]
                | polars into-lazy
                | polars group-by a
                | polars agg {
                    b_min: (polars col b | polars min)
                    b_max: (polars col b | polars max)
                    b_sum: (polars col b | polars sum)
                 }
                | polars collect
                | polars sort-by a
  ╭───┬───┬───────┬───────┬───────╮
  │ # │ a │ b_min │ b_max │ b_sum │
  ├───┼───┼───────┼───────┼───────┤
  │ 0 │ 1 │     2 │     4 │     6 │
  │ 1 │ 2 │     4 │     6 │    10 │
  ╰───┴───┴───────┴───────┴───────╯

```

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users now can use a mix of lists of expressions and
records of expressions where previously only lists of expressions were
accepted (e.g., in `select`, `with-column`, and `agg`).

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Example tests were added to `select`, `with-column`, and `agg`.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-14 16:56:52 -07:00
Mussar
d601abaee0
chore: move 'job' to experimental category (#15568)
# Description

The 'job' command was incorrectly placed into the "Strings" category
rather than the "Experimental" category like its subcommands. This PR
resolves that issues.

# User-Facing Changes

Changes to where the `job` command is found when using the `help`
command or reading the documentation.
2025-04-14 22:28:16 +02:00
pyz4
ceaa0f9375
polars: add new command polars over (#15551)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
Introducing a basic implementation of the polars expression for window
functions: `over`
(https://docs.pola.rs/api/python/stable/reference/expressions/api/polars.Expr.over.html).
Note that this PR only implements the default values for the sorting and
`mapping_strategy` parameters. Implementations for other values for
these parameters may be added in a future PR, as the demand arises.

```nushell
 # Compute expression over an aggregation window
  > [[a b]; [x 2] [x 4] [y 6] [y 4]]
        | polars into-lazy
        | polars select a (polars col b | polars cumulative sum | polars over a | polars as cum_b)
        | polars collect
  ╭───┬───┬───────╮
  │ # │ a │ cum_b │
  ├───┼───┼───────┤
  │ 0 │ x │     2 │
  │ 1 │ x │     6 │
  │ 2 │ y │     6 │
  │ 3 │ y │    10 │
  ╰───┴───┴───────╯

# Compute expression over an aggregation window where partitions are defined by expressions
  > [[a b]; [x 2] [X 4] [Y 6] [y 4]]
        | polars into-lazy
        | polars select a (polars col b | polars cumulative sum | polars over (polars col a | polars lowercase) | polars as cum_b)
        | polars collect
  ╭───┬───┬───────╮
  │ # │ a │ cum_b │
  ├───┼───┼───────┤
  │ 0 │ x │     2 │
  │ 1 │ X │     6 │
  │ 2 │ Y │     6 │
  │ 3 │ y │    10 │
  ╰───┴───┴───────╯
```
 
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. This PR seeks to add a new command only.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Example tests are included.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-14 08:59:48 -07:00
pyz4
d31b7024d8
polars: update get- datetime components commands to allow expressions as inputs (#15557)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR updates the following functions so they may also be used in a
polars expression:

- `polars get-day`
- `polars get-hour`
- `polars get-minute`
- `polars get-month`
- `polars get-nanosecond`
- `polars get-ordinal`
- `polars get-second`
- `polars get-week`
- `polars get-weekday`
- `polars get-year`

Below examples provide a comparison of the two contexts in which each of
these commands may be used:

```nushell
# Returns day from a date (current use case)
  > let dt = ('2020-08-04T16:39:18+00:00' | into datetime --timezone 'UTC');
    let df = ([$dt $dt] | polars into-df);
    $df | polars get-day
  ╭───┬───╮
  │ # │ 0 │
  ├───┼───┤
  │ 0 │ 4 │
  │ 1 │ 4 │
  ╰───┴───╯

# Returns day from a date in an expression (additional use case provided by this PR)
  > let dt = ('2020-08-04T16:39:18+00:00' | into datetime --timezone 'UTC');
    let df = ([$dt $dt] | polars into-df);
    $df | polars select (polars col 0 | polars get-day)
  ╭───┬───╮
  │ # │ 0 │
  ├───┼───┤
  │ 0 │ 4 │
  │ 1 │ 4 │
  ╰───┴───╯
```

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Each of these functions retains its current
behavior and gains the benefit that they can now be used in an
expression as well.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Tests have been added to each of the examples.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-14 08:59:02 -07:00
pyz4
9dd30d7756
polars: update polars lit to handle nushell Value::Duration and Value::Date types (#15564)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR seeks to expand `polars lit` to handle additional nushell types:
Value::Date and Value::Duration. This change is especially relevant to
the `polars filter` command, where expressions would then directly
incorporate Value::Date and Value::Duration types as literals. See one
such example below.

```nushell
#  Filter dataframe for rows where dt is within the last 2 days of the maximum dt value
  > [[dt val]; [2025-04-01 1] [2025-04-02 2] [2025-04-03 3] [2025-04-04 4]] | polars into-df | polars filter ((polars col dt) > ((polars col dt | polars max | $in - 2day)))
  ╭───┬─────────────────────┬─────╮
  │ # │          dt         │ val │
  ├───┼─────────────────────┼─────┤
  │ 0 │ 04/03/25 12:00:00AM │   3 │
  │ 1 │ 04/04/25 12:00:00AM │   4 │
  ╰───┴─────────────────────┴─────╯
```

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users now can directly access Value::Date and
Value::Duration types as literals in polars expressions.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Several additional examples added to `polars lit` and `polars filter`

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-14 08:58:07 -07:00
Firegem
eff9305eb3
Allow spreading arguments of kill command (#15558)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This changes the signature of `kill` from `kill pid ...rest` to `kill
...pid`.

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
Users will now be able to spread a list of pids to the `kill` command,
whereas they'd have to specify the first separately before.

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
👍 

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-13 07:50:04 -05:00
pyz4
885b87a842
polars: add new command polars convert-time-zone (#15550)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This is a direct port of the python polars command `convert_time_zone`
(https://docs.pola.rs/api/python/stable/reference/series/api/polars.Series.dt.convert_time_zone.html).
Consistent with the rust/python implementation, naive datetimes are
treated as if they are in UTC time.

```nushell
  # Convert timezone for timezone-aware datetime
  > ["2025-04-10 09:30:00 -0400" "2025-04-10 10:30:00 -0400"] | polars into-df
                    | polars as-datetime "%Y-%m-%d %H:%M:%S %z"
                    | polars select (polars col datetime | polars convert-time-zone "Europe/Lisbon")
  ╭───┬───────────────────────╮
  │ # │       datetime        │
  ├───┼───────────────────────┤
  │ 0 │ 04/10/2025 02:30:00PM │
  │ 1 │ 04/10/2025 03:30:00PM │
  ╰───┴───────────────────────╯

  # Timezone conversions for timezone-naive datetime will assume the original timezone is UTC
  > ["2025-04-10 09:30:00" "2025-04-10 10:30:00"] | polars into-df
                    | polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
                    | polars select (polars col datetime | polars convert-time-zone "America/New_York")
  ╭───┬───────────────────────╮
  │ # │       datetime        │
  ├───┼───────────────────────┤
  │ 0 │ 04/10/2025 05:30:00AM │
  │ 1 │ 04/10/2025 06:30:00AM │
  ╰───┴───────────────────────╯
```

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
No breaking changes. Users have access to a new command `polars
convert-time-zone`

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->
Example tests have been added.

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-11 14:08:40 -07:00
whi
017daeed18
create nu_plugin_node_example.js (#15482)
example like
[nu_plugin_python_example.py](https://github.com/nushell/nushell/blob/main/crates/nu_plugin_python/nu_plugin_python_example.py)
2025-04-11 21:18:46 +02:00
Loïc Riegel
c8c018452f
Bugfix chrono panic + hotifx PR15544 (#15549)
Closes  #13972

# Description
First commit: a hotfix concerning my last PR #15544! I had a
``unwrap_or_default`` that resulted in all years before ~1800 being
considered as "now", because the ``num_nanoseconds()`` overflowed.
Cc @fdncred 

Second: about #13972
Negative years are not allowed with RFC 2822 formatting, so I fallback
RTC 3339 in such cases.

If you want you might Rebase and Merge, and not squash.

# User-Facing Changes
On master 🔴 :
```nu
~> {year: 1900} | into datetime
Mon, 1 Jan 1900 00:00:00 +0200 (125 years ago)
# OK

~> {year: 1000} | into datetime
Wed, 1 Jan 1000 00:00:00 +0200 (now)
# NOT OK: now?

~> {year: -1000} | into datetime
-1000-01-01T00:00:00+02:00 (now)
# NOT OK: now?

~> {year: -1000} | into datetime | format date 
Error:   × Main thread panicked.
  ├─▶ at C:\Users\RIL1RT\.cargo\registry\src\index.crates.io-6f17d22bba15001f\chrono-0.4.39\src\datetime\mod.rs:626:14
  ╰─▶ writing rfc2822 datetime to string should never fail: Error
  help: set the `RUST_BACKTRACE=1` environment variable to display a backtrace.
# NOT OK: panics
```

On this branch 🟢 :
```nu
~> {year: 1900} | into datetime
Mon, 1 Jan 1900 00:00:00 +0200 (in 125 years)
~>  {year: 1000} | into datetime
Wed, 1 Jan 1000 00:00:00 +0200 (1025 years ago)
~> {year: -1000} | into datetime
-1000-01-01T00:00:00+02:00 (3025 years ago)
~> {year: -1000} | into datetime | format date
-1000-01-01T00:00:00+02:00
~> '3000 years ago' | date from-human | format date
-0975-04-11T18:18:24.301641100+02:00
```

# Tests + Formatting

# After Submitting
Nothing required IMO
2025-04-11 11:52:42 -05:00
pyz4
1a0778d77e
polars: add new command polars replace-time-zone (#15538)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR seeks to add a direct port of the python polars
`replace_time_zone` command in the `dt` namespace
(https://docs.pola.rs/api/python/stable/reference/series/api/polars.Series.dt.replace_time_zone.html).

Please note: I opted for two keywords "dt" and "replace-time-zone" to
map directly with the implementation in both the rust and python
packages, but I'm open to simplifying it to just one keyword, or `polars
replace-time-zone`

```nushell
#  Apply timezone to a naive datetime
  > ["2021-12-30 00:00:00" "2021-12-31 00:00:00"] | polars into-df
                    | polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
                    | polars select (polars col datetime | polars dt replace-time-zone "America/New_York")
  ╭───┬─────────────────────╮
  │ # │      datetime       │
  ├───┼─────────────────────┤
  │ 0 │ 12/30/21 12:00:00AM │
  │ 1 │ 12/31/21 12:00:00AM │
  ╰───┴─────────────────────╯

#  Apply timezone with ambiguous datetime
  > ["2025-11-02 00:00:00", "2025-11-02 01:00:00", "2025-11-02 02:00:00", "2025-11-02 03:00:00"]
                    | polars into-df
                    | polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
                    | polars select (polars col datetime | polars dt replace-time-zone "America/New_York" --ambiguous null)
  ╭───┬─────────────────────╮
  │ # │      datetime       │
  ├───┼─────────────────────┤
  │ 0 │ 11/02/25 12:00:00AM │
  │ 1 │                     │
  │ 2 │ 11/02/25 02:00:00AM │
  │ 3 │ 11/02/25 03:00:00AM │
  ╰───┴─────────────────────╯

#  Apply timezone with nonexistent datetime
  > ["2025-03-09 01:00:00", "2025-03-09 02:00:00", "2025-03-09 03:00:00", "2025-03-09 04:00:00"]
                    | polars into-df
                    | polars as-datetime "%Y-%m-%d %H:%M:%S" --naive
                    | polars select (polars col datetime | polars dt replace-time-zone "America/New_York" --nonexistent null)
  ╭───┬─────────────────────╮
  │ # │      datetime       │
  ├───┼─────────────────────┤
  │ 0 │ 03/09/25 01:00:00AM │
  │ 1 │                     │
  │ 2 │ 03/09/25 03:00:00AM │
  │ 3 │ 03/09/25 04:00:00AM │
  ╰───┴─────────────────────╯
```

# User-Facing Changes
No breaking changes. The user will be able to access the new command.

# Tests + Formatting
See example tests.

# After Submitting
2025-04-11 09:09:37 -07:00
Maxim Zhiburt
d75aa7ed1b
fix f25525b (#15500)
This addresses color issue; Yeees just got forgotten it :(
As far as I understand an acceptance test can't be created because ansi
got stripped in `nu!`. (for future regressions)

But wrapping I need to take a deeper look.
Maybe in an hour.

cc: @fdncred
2025-04-11 08:02:01 -05:00
Loïc Riegel
39edd7e080
Bugfix: datetime parsing and local timezones (#15544)
Hi,
This PR should close 3 issues
- [DMY date format is parsed inconsistently
#14123](https://github.com/nushell/nushell/issues/14123)
- [into datetime doesnt't work with --format and ignores user's locale
#11015](https://github.com/nushell/nushell/issues/11015)
- [into datetime: iinconsistent and incrrect behaviour regarding
timezones #13823](https://github.com/nushell/nushell/issues/13823)


# Description
- Allow to parse only dates or only times with --format
- Use local timezone depending on the input. Ex: I'm in France, so show
dates with +0100 in winter and +0200 in summer.

```nushell
# Concerning #13823

> "2020-01-01 12:00" | into datetime
Wed, 1 Jan 2020 12:00:00 +0100 (5 years ago)
# OK, it's my timezone in winter time

> "2020-06-01 12:00" | into datetime
Mon, 1 Jun 2020 12:00:00 +0200 (4 years ago)
# OK, it's my timezone in summertime

> ("2024-10-27 12:00" | into datetime) - ("2024-10-27 00:00" | into datetime)
13hr
# Ok, because we switched from summer to winter time on 2025-10-27, so there are actually 13h between midnight and noon

> "2020-01-01 12:00" | into datetime --format "%Y-%m-%d %H:%M"
Wed, 1 Jan 2020 12:00:00 +0100 (5 years ago)
# OK: timezone is assumed to be local, and +0100 is my timezone in winter

# Concerning #14123 and #11015
# Flexible parsing still works like before, which could be counter-intuitive, but it's flexible parsing
# with one difference: the timezone is local
> '12-01-2001' | into datetime
Sat, 1 Dec 2001 00:00:00 +0100 (23 years ago)
# OK, +0100 is my timezone in winter time. If I run it with nushell 0.103.0 in summer time, I get +0200
> '13-01-2001' | into datetime
Sat, 13 Jan 2001 00:00:00 +0100 (24 years ago)

## If you want, you can use the --format option to parse a date or a time (before, it had to be a date + time)
## Notice here again the timezone is correct depending on winter/summer time
~> "06.03.2023" | into datetime -f "%d.%m.%Y"
Mon, 6 Mar 2023 00:00:00 +0100 (2 years ago)
~> "06.03.2023" | into datetime -f "%m.%d.%Y"
Sat, 3 Jun 2023 00:00:00 +0200 (2 years ago)
> "10:00" | into datetime --format "%H:%M"
Thu, 10 Apr 2025 10:00:00 +0200 (9 hours ago)
```

# User-Facing Changes
See above

# Tests + Formatting


# After Submitting
I'll down something for the release notes, if this is merged in time 😄
2025-04-11 07:48:39 -05:00
vansh284
61dbcf3de6
Substring Match Algorithm (#15511)
<!--
if this PR closes one or more issues, you can automatically link the PR
with
them by using one of the [*linking
keywords*](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword),
e.g.
- this PR should close #xxxx
- fixes #xxxx

you can also mention related issues, PRs or discussions!
-->

# Description
<!--
Thank you for improving Nushell. Please, check our [contributing
guide](../CONTRIBUTING.md) and talk to the core team before making major
changes.

Description of your pull request goes here. **Provide examples and/or
screenshots** if your changes affect the user experience.
-->
This PR should close #15474 .

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
When users set the match algorithm to 'substring' by modifying
`$env.config` to `$env.config.completions.algorithm = "substring"``),
completions are done based on substring matches.
This was previously possible by setting `positional` to be false in
custom completers, but doing so now logs a warning as this feature is
set to be deprecated and replaced by the new way of setting the matching
algorithm to substring based.
2025-04-11 05:15:36 -04:00
Jack Wright
f8ed4b45fd
Introducing polars into-schema (#15534)
# Description
Introduces `polars into-schema` which allows converting Values such as
records to a schema. This implicitly happens when when passing records
into commands like `polars into-df` today. This allows you to convert to
a schema object ahead of time and reuse the schema object. This can be
useful for guaranteeing your schema object is correct.

```nu
> ❯ : let schema = ({name: str, type: str} | polars into-schema)

> ❯ : ls | select name type | polars into-lazy -s $schema | polars schema
╭──────┬─────╮
│ name │ str │
│ type │ str │
╰──────┴─────╯
```

# User-Facing Changes
- Introduces `polars into-schema` allowing records to be converted to
schema objects.
2025-04-10 16:07:44 -07:00
Loïc Riegel
dfca117551
Feat: construct datetime from record (#15455)
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:🐚: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.
2025-04-10 15:33:06 +02:00
Darren Schroeder
29eb109b1e
try to fix datetime-diff for ms, us, ns (#15537)
# Description

This PR tries to fix the datetime-diff custom command so that it
includes ms, us, ns.

Difference in the banner in 2 separate starts.

### Old
```nushell
It's been this long since Nushell's first commit:
5yrs 10months 29days 9hrs 1min 47secs
```

### New
```nushell
It's been this long since Nushell's first commit:
5yrs 10months 29days 9hrs 1min 22secs 49ms 885µs
```

There should be ns above on the new one, not sure why there isn't. It
could have something to do with how the banner works but i'll save that
for another PR.

🤔 It could be because there are no fractional seconds in the math?
`datetime-diff (date now) 2019-05-10T09:59:12-07:00`. However, I'm not
sure why `date now` has no nanoseconds. Oh, wait. I think that's because
MacOS doesn't have nanosecond precision?
```
❯ ^date +%s.%N
1744251636.365003000
```

Closes https://github.com/nushell/nushell/issues/15524

/cc @NotTheDr01ds 

# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo
fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to
check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make
sure to [enable developer
mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the
tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu # or use an `env_change` hook to activate it
automatically
> toolkit check pr
> ```
-->

# After Submitting
<!-- If your PR had any user-facing changes, update [the
documentation](https://github.com/nushell/nushell.github.io) after the
PR is merged, if necessary. This will help us keep the docs up to date.
-->
2025-04-10 06:52:11 -05:00
zc he
70d8163181
fix(lsp): more accurate command name highlight/rename (#15540)
# Description

The `command` version of #15523 

# User-Facing Changes

Before:

<img width="394" alt="image"
src="https://github.com/user-attachments/assets/cdd1954d-c120-4aa4-8625-8a0f817ddebf"
/>

After:

<img width="431" alt="image"
src="https://github.com/user-attachments/assets/66fa17cd-2e6f-4305-a08a-df1c1617cfe8"
/>

And the renaming of that command finally works as expected.

Of course the identification of module prefixes in command calls is
still missing. I kinda feel there's no power-efficient way to do it.
I'll put low priority to that feature.

# Tests + Formatting

+1

# After Submitting
2025-04-10 06:26:43 -05:00
zc he
e4cef8a154
fix(lsp): several edge cases of inaccurate references (#15523)
# Description

Sometimes recognizing identical concepts in nushell can be difficult.
This PR fixes some cases.

# User-Facing Changes

## Before:

<img width="317" alt="image"
src="https://github.com/user-attachments/assets/40567fd2-4cf4-44bb-8845-5f39935f41bb"
/>
<img width="317" alt="image"
src="https://github.com/user-attachments/assets/0cc21aab-8c8a-4bdd-adaf-70117e46c88d"
/>
<img width="276" alt="image"
src="https://github.com/user-attachments/assets/2820f958-b1aa-4bf1-b2ec-36e3191dd1aa"
/>
<img width="311" alt="image"
src="https://github.com/user-attachments/assets/407fb20f-ca5a-42a2-b0ac-791a7ee8497a"
/>

## After:

<img width="317" alt="image"
src="https://github.com/user-attachments/assets/91ca595f-36c5-4081-ba19-4800eb89cbec"
/>
<img width="317" alt="image"
src="https://github.com/user-attachments/assets/222aa0d1-b9c6-441c-8ecd-66ae91c7d397"
/>
<img width="275" alt="image"
src="https://github.com/user-attachments/assets/7b3122d3-ed5a-4bee-8e35-5ef01abc25a1"
/>
<img width="316" alt="image"
src="https://github.com/user-attachments/assets/2c026055-5962-4d4c-97d4-c453a2fef82b"
/>

# Tests + Formatting

+3

# After Submitting
2025-04-09 21:15:35 -05:00
zc he
15146e68ad
fix(lsp): workspace wide ops may panic in certain conditions (#15514)
# Description

I've made the panic reproducible in test case
`workspace::tests::quoted_command_reference_in_workspace`.
This PR fixes that by parsing + merging 1 more time, IMO it's a small
price to pay for workspace-wide heavy requests.

# User-Facing Changes

bug fix

# Tests + Formatting

made 1 case harder

# After Submitting
2025-04-09 20:38:17 -05:00
Jack Wright
b0f9cda9b5
Introduction of NuDataType and polars dtype (#15529)
# Description
This pull request does a lot of the heavy lifting needed to supported
more complex dtypes like categorical dtypes. It introduces a new
CustomValue, NuDataType and makes NuSchema a full CustomValue. Further
more it introduces a new command `polars into-dtype` that allows a dtype
to be created. This can then be passed into schemas when they are
created.

```nu
> ❯ : let dt = ("str" | polars to-dtype)

> ❯ : [[a b]; ["one" "two"]] | polars into-df -s {a: $dt, b: str} | polars schema
╭───┬─────╮
│ a │ str │
│ b │ str │
╰───┴─────╯
```

# User-Facing Changes
- Introduces new command `polars into-dtype`, allows dtype variables to
be passed in during schema creation.
2025-04-09 08:13:49 -07:00
dependabot[bot]
c0b944edb6
build(deps): bump indexmap from 2.8.0 to 2.9.0 (#15531)
Bumps [indexmap](https://github.com/indexmap-rs/indexmap) from 2.8.0 to
2.9.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/indexmap-rs/indexmap/blob/main/RELEASES.md">indexmap's
changelog</a>.</em></p>
<blockquote>
<h2>2.9.0 (2025-04-04)</h2>
<ul>
<li>Added a <code>get_disjoint_mut</code> method to
<code>IndexMap</code>, matching Rust 1.86's
<code>HashMap</code> method.</li>
<li>Added a <code>get_disjoint_indices_mut</code> method to
<code>IndexMap</code> and <code>map::Slice</code>,
matching Rust 1.86's <code>get_disjoint_mut</code> method on
slices.</li>
<li>Deprecated the <code>borsh</code> feature in favor of their own
<code>indexmap</code> feature,
solving a cyclic dependency that occured via
<code>borsh-derive</code>.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="1818d4140d"><code>1818d41</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/387">#387</a>
from cuviper/release-2.9.0</li>
<li><a
href="9f4998341b"><code>9f49983</code></a>
Release 2.9.0</li>
<li><a
href="582a90fda3"><code>582a90f</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/386">#386</a>
from cuviper/de-borsh</li>
<li><a
href="90117397b6"><code>9011739</code></a>
Deprecate the &quot;borsh&quot; feature</li>
<li><a
href="0a836e8648"><code>0a836e8</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/238">#238</a>
from NiklasJonsson/get_many_mut</li>
<li><a
href="434d7ac6d1"><code>434d7ac</code></a>
Avoid let-else for MSRV's sake</li>
<li><a
href="5be552d557"><code>5be552d</code></a>
Implement additional suggestions from review</li>
<li><a
href="4e1d8cef47"><code>4e1d8ce</code></a>
Address review feedback</li>
<li><a
href="5aec9ec674"><code>5aec9ec</code></a>
Implement get_disjoint_mut for arrays of keys</li>
<li><a
href="d10de30e74"><code>d10de30</code></a>
Merge pull request <a
href="https://redirect.github.com/indexmap-rs/indexmap/issues/385">#385</a>
from iajoiner/docs/macros</li>
<li>Additional commits viewable in <a
href="https://github.com/indexmap-rs/indexmap/compare/2.8.0...2.9.0">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=indexmap&package-manager=cargo&previous-version=2.8.0&new-version=2.9.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)


</details>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2025-04-09 13:15:29 +08:00
Loïc Riegel
08940ba4f8
bugfix: wrong display of human readable string (#15522)
I think after that we can close  #14790

# Description
So the issue was the tiny time delta between the moment the "date
form-human" command is executed, and the moment the value gets
displayed, using chrono_humanize.

When in inputing "in 30 seconds", we currently get:
```
[crates\nu-protocol\src\value\mod.rs:950:21] HumanTime::from(*val) = HumanTime(
    TimeDelta {
        secs: 29,
        nanos: 992402700,
    },
)```
And with "now":
```
crates\nu-protocol\src\value\mod.rs:950:21] HumanTime::from(*val) =
HumanTime(
    TimeDelta {
        secs: -1,
        nanos: 993393200,
    },
)
```

My solution is to round this timedelta to seconds and pass this to chrono_humanize.
Example: instead of passing (-1s + 993393200ns), we pass 0s.
Example: instead of passing (29s + 992402700ns), we pass 30s


# User-Facing Changes
Before 🔴 
```nushell
~> "in 3 days" | date from-human
Fri, 11 Apr 2025 09:06:36 +0200 (in 2 days)
~> "in 30 seconds" | date from-human
Tue, 8 Apr 2025 09:07:09 +0200 (in 29 seconds)
```

After those changes 🟢 
```nushell
~> "in 3 days" | date from-human
Fri, 11 Apr 2025 09:03:47 +0200 (in 3 days)
~> "in 30 seconds" | date from-human
Tue, 8 Apr 2025 09:04:28 +0200 (in 30 seconds)
```

# Tests + Formatting
<!--
Don't forget to add tests that cover your changes.

Make sure you've run and fixed any issues with these commands:

- `cargo fmt --all -- --check` to check standard code formatting (`cargo fmt --all` applies these changes)
- `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used` to check that you're using the standard code style
- `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging))
- `cargo run -- -c "use toolkit.nu; toolkit test stdlib"` to run the tests for the standard library

> **Note**
> from `nushell` you can also use the `toolkit` as follows
> ```bash
> use toolkit.nu  # or use an `env_change` hook to activate it automatically
> toolkit check pr
> ```
-->

# After Submitting
<!-- If your PR had any user-facing changes, update [the documentation](https://github.com/nushell/nushell.github.io) after the PR is merged, if necessary. This will help us keep the docs up to date. -->
2025-04-08 06:29:16 -05:00
Stefan Holderbach
ecb9799b6a
Fix future clippy lints (#15519)
- suggestions for tersity using helpers
2025-04-08 08:51:12 +08:00
zc he
a886e30e04
fix(lsp): parser_info based id detection for use/overlay keywords (#15517)
# Description

Now, with PWD correctly set in #15470 , identifiers in
`use/hide/overlay` commands can be identified using a more robust
method, i.e. module_id from `parser_info`.

# User-Facing Changes

bug fix

# Tests + Formatting

+1 (fails without this PR)

# After Submitting
2025-04-07 19:31:03 -05:00
pyz4
147009a161
polars into-df/polars into-lazy: --schema will not throw error if only some columns are defined (#15473)
# Description
The current implementation of `polars into-df` and `polars into-lazy`
will throw an error if `--schema` is provided but not all columns are
defined. This PR seeks to remove this requirement so that when a partial
`--schema` is provided, the types on the defined columns are overridden
while the remaining columns take on their default types.

**Current Implementation**
```
$ [[a b]; [1 "foo"] [2 "bar"]] | polars into-df -s {a: str} | polars schema
Error:   × Schema does not contain column: b
   ╭─[entry #88:1:12]
 1 │ [[a b]; [1 "foo"] [2 "bar"]] | polars into-df -s {a: str} | polars schema
   ·            ─────
   ╰────
```

**New Implementation (no error thrown on partial schema definition)**
Column b is not defined in `--schema`
```
$ [[a b]; [1 "foo"] [2 "bar"]] | polars into-df --schema {a: str} | polars schema
╭───┬─────╮
│ a │ str │
│ b │ str │
╰───┴─────╯
```

# User-Facing Changes
Soft breaking change: The user's previous (erroneous) code that would
have thrown an error would no longer throw an error. The user's previous
working code will still work.

# Tests + Formatting


# After Submitting
2025-04-07 15:58:37 -07:00
Loïc Riegel
12a1eefe73
Move human date parsing into new command date from-human (#15495)
No related issue.
Decided in nushell's weekly meeting: see [meeting
notes](https://hackmd.io/rA1YecqjRh6I5m8dTq7BHw)

# Description
Converting a date as a human readable string to a datetime:
- currently: using the ``into datetime`` command
- after this change: using ``date from-human`` command

Also moved the ``--list-human`` flag to the new command.

# User-Facing Changes
- Users have to use a new command for parsing human readable datetimes.

Result:
```nushell
~> date from-human --list
╭────┬───────────────────────────────────┬──────────────╮
│  # │ parseable human datetime examples │    result    │
├────┼───────────────────────────────────┼──────────────┤
│  0 │ Today 18:30                       │ in 6 hours   │
│  1 │ 2022-11-07 13:25:30               │ 2 years ago  │
│  2 │ 15:20 Friday                      │ in 6 days    │
│  3 │ This Friday 17:00                 │ in 6 days    │
│  4 │ 13:25, Next Tuesday               │ in 3 days    │
│  5 │ Last Friday at 19:45              │ 16 hours ago │
│  6 │ In 3 days                         │ in 2 days    │
│  7 │ In 2 hours                        │ in 2 hours   │
│  8 │ 10 hours and 5 minutes ago        │ 10 hours ago │
│  9 │ 1 years ago                       │ a year ago   │
│ 10 │ A year ago                        │ a year ago   │
│ 11 │ A month ago                       │ a month ago  │
│ 12 │ A week ago                        │ a week ago   │
│ 13 │ A day ago                         │ a day ago    │
│ 14 │ An hour ago                       │ an hour ago  │
│ 15 │ A minute ago                      │ a minute ago │
│ 16 │ A second ago                      │ now          │
│ 17 │ Now                               │ now          │
╰────┴───────────────────────────────────┴──────────────╯

~> "2 days ago" | date from-human
Thu, 3 Apr 2025 12:03:33 +0200 (2 days ago)

~> "2 days ago" | into datetime
Error: nu:🐚:datetime_parse_error

  × Unable to parse datetime: [2 days ago].
   ╭─[entry #5:1:1]
 1 │ "2 days ago" | into datetime
   · ──────┬─────
   ·       ╰── datetime parsing failed
   ╰────
  help: Examples of supported inputs:
         * "5 pm"
         * "2020/12/4"
         * "2020.12.04 22:10 +2"
         * "2020-04-12 22:10:57 +02:00"
         * "2020-04-12T22:10:57.213231+02:00"
         * "Tue, 1 Jul 2003 10:52:37 +0200"
```

# Tests + Formatting
Fmt, clippy 🆗 
Tests 🆗 

> Note: I was able to reactivate one unit test in the ``into datetime``
command

# After Submitting
Here since the user facing changes are significant, I think we should
communicate in the released notes. Otherwise the automatically generated
documentation should be enough IMO.
2025-04-07 07:44:55 -05:00
Stefan Holderbach
0f8f3bcf9a
Fix Exbibyte parsing (#15515)
Closes #15502

# Description
The parsing of Exbibytes used the wrong base unit before converting.

# User-Facing Changes
`1EiB` etc. will now be parsed correctly

# Tests + Formatting
(-)
2025-04-07 13:36:23 +02:00
Loïc Riegel
639f4bd499
Replace some PipelineMismatch by OnlySupportsThisInputType by shell error (#15447)
sub-issue of #10698 according to @sholderbach 

(Description largely edited, since the scope of the PR changed)

# Description
Context: `ShellError::OnlySupportsThisInputType` was a duplicate of
`ShellError::PipelineMismatch`

so I
- replaced some occurences of PipelineMismatch by
OnlySupportsThisInputType

For another PR
- replace the remaining occurences
- removed OnlySupportsThisInputType from nu-protocol

# User-Facing Changes
The error message will be different -> but consistent

# Tests + Formatting
OK

# After Submitting
Nothing required
2025-04-07 12:25:27 +02:00
Douglas
e82df7c1c9
Reminder comment to update doc when adding $nu constants (#15481)
# Description

As requested in review on
https://github.com/nushell/nushell.github.io/pull/1860 - This adds a
reminder comment requesting that contributors update that doc page when
adding new constants.

# User-Facing Changes

None

# Tests + Formatting

Comment-only

# After Submitting

This PR should only be merged after
https://github.com/nushell/nushell.github.io/pull/1860 is merged into
the doc.
2025-04-07 00:38:17 -04:00
zc he
41f4d0dcbc
refactor(lsp): align markdown doc string with output of --help (#15508)
#15499 reminds me of the discrepancies between lsp hover docs and
`--help` outputs.

# Description

# User-Facing Changes

Before:

<img width="610" alt="image"
src="https://github.com/user-attachments/assets/f73f7ace-5c1b-4380-9921-fb4783bdb187"
/>

After:

<img width="610" alt="image"
src="https://github.com/user-attachments/assets/96de3ffe-e37b-41b1-88bb-123eeb72ced2"
/>

Output of `if -h` as a reference:

```
Usage:
  > if <cond> <then_block> (else <else_expression>)

Flags:
  -h, --help: Display the help message for this command

Parameters:
  cond <variable>: Condition to check.
  then_block <block>: Block to run if check succeeds.
  "else" + <one_of(block, expression)>: Expression or block to run when the condition is false. (optional)

```

# Tests + Formatting

Refined

# After Submitting
2025-04-06 08:37:59 -05:00