follow-up to
- https://github.com/nushell/nushell/pull/11151
> **Important**
> land only between 0.89 and 0.90
# Description
this PR hides the `std testing` module from the outside.
- moves `nu-std/std/testing.nu` to `nu-std/testing.nu`
- removes the module from the standard library list of modules to parse
- fixes `toolkit.nu` and the CI
# User-Facing Changes
`std testing` won't be part of the standard library anymore.
# Tests + Formatting
# After Submitting
I've noticed that two tests fail on my system when running `toolkit
check pr`. The reason for this is that my locale is set to German. `ls`
is translated, so checking the error message will only work on systems
set to English.
I've adapted the test to check the exit code instead.
Alternatively, we could set the locale, I am not sure if the `nu!` macro
supports that though.
# Description
I've had a few PRs fail clippy in CI after they pass `toolkit check pr`
because the clippy settings are different. This brings `toolkit.nu` into
alignment with CI and leaves notes to prompt future synchronization.
# User-Facing Changes
N/A
# Tests + Formatting
`cargo` output elided:
```
❯ toolkit check pr
running `toolkit fmt`
running `toolkit clippy`
running `toolkit clippy` on tests
running `toolkit clippy` on plugins
running `toolkit test`
running `toolkit test stdlib`
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`
```
# After Submitting
N/A
# Description
when i try out a PR, i always end up running `cargo run` but then i
never know if i'm inside my install of Nushell or a PR 👀
in this PR i propose to add a `run` command to the `toolkit.nu` which
- runs the current revision inside `cargo run`
- adds a clear right prompt to make sure one knows they are in `cargo
run`
# User-Facing Changes
an example after running `toolkit run`
# Tests + Formatting
# After Submitting
Align the clippy checks done by `toolkit check pr` with the ones done by
github CI when you post a PR.
Motivated in no small part by my frustration at having the third PR in
one day fail due to a lint that `toolkit check pr` didn't find!
# Description
Change definition of `toolkit clippy`
* always run checks on all crates in the workspace
* always run checks on tests as well as non-test code
* don't check for `unwrap_used`. There are many (legit) uses of
`.unwrap()` in tests,
*
# User-Facing Changes
Changes to `toolkit clippy`:
* remove `--workspace` switch
* `--features` is no longer mutually exclusive with `--workspace`
# Tests + Formatting
n/a
# 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.
-->
---------
Co-authored-by: amtoine <stevan.antoine@gmail.com>
related to
- https://github.com/nushell/nushell/pull/9973
- https://github.com/nushell/nushell/pull/9918
thanks to @jntrnr and their super useful tips on this PR, i learned
about the parser + evaluation, so 🙏
# Description
because we already have `null` as the value of the type `nothing` and as
a followup to the two other attempts of mine, i propose to remove the
redundant `$nothing` built-in variable 😋
this PR is the first step, deprecating `$nothing`.
a followup PR will remove it altogether and wait for 0.87 👍⚙️ **details**: a new `NOTHING_VARIABLE_ID = 3` has been added,
parsing `$nothing` will create it, finally a `Value::Nothing` will be
produced and a warning will be reported.
this PR already fixes the `toolkit.nu` module so that it does not throw
a bunch of warnings each time 👌
# User-Facing Changes
`$nothing` is now deprecated and will be removed in 0.87
```nushell
> $nothing
Error: × Deprecated variable
╭─[entry #1:1:1]
1 │ $nothing
· ────┬───
· ╰── `$nothing` is deprecated and will be removed in 0.87.
╰────
help: Use `null` instead
```
# Tests + Formatting
tests have been updated, especially
- `nothing_fails_string`
- `nothing_fails_int`
which use a variable called `nil` now to make sure `nothing` does not
support cell paths 👍
# After Submitting
classic deprecation mention 👍
# Description
Fixes: #10450
This pr differentiating between `--x: bool` and `--x`
Here are examples which demostrate difference between them:
```nushell
def a [--x: bool] { $x };
a --x # not allowed, you need to parse a value to the flag.
a # it's allowed, and the value of `$x` is false, which behaves the same to `def a [--x] { $x }; a`
```
For boolean flag with default value, it works a little bit different to
#10450 mentioned:
```nushell
def foo [--option: bool = false] { $option }
foo # output false
foo --option # not allowed, you need to parse a value to the flag.
foo --option true # output true
```
# User-Facing Changes
After the pr, the following code is not allowed:
```nushell
def a [--x: bool] { $x }; a --x
```
Instead, you have to pass a value to flag `--x` like `a --x false`. But
bare flag works in the same way as before.
## Update: one more breaking change to help on #7260
```
def foo [--option: bool] { $option == null }
foo
```
After the pr, if we don't use a boolean flag, the value will be `null`
instead of `true`. Because here `--option: bool` is treated as a flag
rather than a switch
---------
Co-authored-by: amtoine <stevan.antoine@gmail.com>
# Description
* The path to the binaries for tests is slightly incorrect. It is
missing the build target when it is set with the `CARGO_BUILD_TARGET`
environment variable. For example, when `CARGO_BUILD_TARGET` is set to
`aarch64-linux-android`, the path to the `nu` binary is:
`./target/aarch64-linux-android/debug/nu`
rather than
`./target/debug/nu`
This is common on Termux since the default target that rustc detects can
cause problems on some projects, such as [python's `cryptography`
package](https://github.com/pyca/cryptography/issues/7248).
This technically isn't a problem specific to Android, but is more likely
to happen on Android due to the latter.
* Additionally, the existing variable named `NUSHELL_CARGO_TARGET` is in
fact the profile, not the build target, so this was renamed to
`NUSHELL_CARGO_PROFILE`. This change is included because without the
rename, the build system would be using `CARGO_BUILD_TARGET` for the
build target and `NUSHELL_CARGO_TARGET` for the build profile, which is
confusing.
* `std path add` tests were missing `android` test
# User-Facing Changes
For those who would like to build nushell on Termux, the unit tests will
pass now.
# Description
This PR updates the toolkit and the build/install scripts to include
`--locked`, also added `extra` feature to the _all_ scripts, and
`--force` to the install scripts.
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- -c "use std testing; testing run-tests --path
crates/nu-std"` 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.
-->
# Description
`version` has always been a bit off regarding the `commit_hash`
😕
i think it was @fdncred who found this trick: `touch`ing the
`crates/nu-cmd-lang/build.rs` file
- won't change the Git index
- will force Nushell to recompile the `version` information correctly
this PR adds a call to `touch` on that file to `toolkit install`.
# User-Facing Changes
`version` should be correct when installing locally with the `toolkit`.
# Tests + Formatting
# After Submitting
<!--
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
Test runner now uses annotations instead of magic function names to pick
up code to run. Additionally skipping tests is now done on annotation
level so skipping and unskipping a test no longer requires changes to
the test code
In order for a function to be picked up by the test runner it needs to
meet following criteria:
* Needs to be private (all exported functions are ignored)
* Needs to contain one of valid annotations (and only the annotation)
directly above the definition, all other comments are ignored
Following are considered valid annotations:
* \# test
* \# test-skip
* \# before-all
* \# before-each
* \# after-each
* \# after-all
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
For years, Nushell has used `let-env` to set a single environment
variable. As our work on scoping continued, we refined what it meant for
a variable to be in scope using `let` but never updated how `let-env`
would work. Instead, `let-env` confusingly created mutations to the
command's copy of `$env`.
So, to help fix the mental model and point people to the right way of
thinking about what changing the environment means, this PR removes
`let-env` to encourage people to think of it as updating the command's
environment variable via mutation.
Before:
```
let-env FOO = "BAR"
```
Now:
```
$env.FOO = "BAR"
```
It's also a good reminder that the environment owned by the command is
in the `$env` variable rather than global like it is in other shells.
# User-Facing Changes
BREAKING CHANGE BREAKING CHANGE
This completely removes `let-env FOO = "BAR"` so that we can focus on
`$env.FOO = "BAR"`.
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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 / Before Submitting
integration scripts to update:
- ✔️
[starship](https://github.com/starship/starship/blob/master/src/init/starship.nu)
- ✔️
[virtualenv](https://github.com/pypa/virtualenv/blob/main/src/virtualenv/activation/nushell/activate.nu)
- ✔️
[atuin](https://github.com/ellie/atuin/blob/main/atuin/src/shell/atuin.nu)
(PR: https://github.com/ellie/atuin/pull/1080)
- ❌
[zoxide](https://github.com/ajeetdsouza/zoxide/blob/main/templates/nushell.txt)
(PR: https://github.com/ajeetdsouza/zoxide/pull/587)
- ✔️
[oh-my-posh](https://github.com/JanDeDobbeleer/oh-my-posh/blob/main/src/shell/scripts/omp.nu)
(pr: https://github.com/JanDeDobbeleer/oh-my-posh/pull/4011)
related to
- https://github.com/nushell/nushell/pull/9357
# Description
with the new `extra` feature introduce in the `toolkit.nu` module in
https://github.com/nushell/nushell/pull/9357, the `--dataframe` option
does not make sense anymore...
this PR changes that and replaces it with `--features: list<string>`.
this has the benefit of simplifying the commands because we can just
pass `--features ($features | str join ",")` to the `cargo` commands
regardless of whether the `$features` list is empty of not 👌
i've also refactored a bit the module:
- break the long `error make -u` lines
- break the long `cargo clippy` command
# User-Facing Changes
devs can now choose which feature to test with the `toolkit` commands.
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
# 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.
-->
related to
closes#9342
complete the install command to install plugins
[
](https://github.com/nushell/nushell/pull/9288)
the issue
toolkit build only builds in debug mode
toolkit install only installs Nushell
toolkit register plugins will install any plugins in the path, in debug
or release
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
# Description
Test runner now performs following actions in order to run tests:
* Module file is opened
* Public function with random name is added to the source code, this
function calls user-specified private function
* Modified module file is saved under random name in $nu.temp-path
* Modified module file is imported in subprocess, injected function is
called by the test runner
# User-Facing Changes
<!-- List of all changes that impact the user experience here. This
helps us keep track of breaking changes. -->
* Test functions no longer need to be exported
* test functions no longer need to reside in separate test_ files
* setup and teardown renamed to before-each and after-each respectively
* before-all and after-all functions added that run before all tests in
given module. This matches the behavior of test runners used by other
languages such as JUnit/TestNG or Mocha
# Tests + Formatting
# After Submitting
---------
Co-authored-by: Kamil <skelly37@protonmail.com>
Co-authored-by: amtoine <stevan.antoine@gmail.com>
# Description
i was installing Nushell and, as we have the `dataframe` feature and
very soon at least the `extra` feature with more and more commands, i
thought it could be cool to have a little `toolkit install` command
😋
# User-Facing Changes
exposes the following command to developers
```
install Nushell and features you want
Usage:
> install ...(features)
Flags:
-h, --help - Display the help message for this command
Parameters:
...features <string>: a space-separated list of feature to install with Nushell
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
# Description
This PR allows you to pass `--dataframe` into `toolkit check pr --fast
--dataframe` in order to check and build with the dataframe feature.
# 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 -A
clippy::needless_collect -A clippy::result_large_err` to check that
you're using the standard code style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
# Description
Enable setup-git-hooks on windows. It works just fine without doing
anything special. More testing from other windows users is welcomed as
there might be a reason it was done that way before.
# User-Facing Changes
`toolkit setup-git-hooks` now work on windows
# Description
until now, a call to `toolkit` alone would give
```bash
Error: nu:🐚:external_command
× External command failed
╭─[entry #2:1:1]
1 │ toolkit
· ───┬───
· ╰── did you mean 'toolkit clippy'?
╰────
help: No such file or directory (os error 2)
```
which i find confusing after a `use toolkit.nu` 🤔
this PR adds a `main` command to `toolkit.nu` which runs the `help`
command on the module.
# User-Facing Changes
now
```
> use toolkit.nu
> toolkit
Usage:
> toolkit
Subcommands:
toolkit check pr - run all the necessary checks and tests to submit a perfect PR
toolkit clippy - check that you're using the standard code style
toolkit fmt - check standard code formatting and apply the changes
toolkit setup-git-hooks - set up git hooks to run:
- `toolkit fmt --check --verbose` on `git commit`
- `toolkit fmt --check --verbose` and `toolkit clippy --verbose` on `git push`
toolkit test - check that all the tests pass
toolkit test stdlib - run the tests for the standard library
Flags:
-h, --help - Display the help message for this command
```
# Tests + Formatting
- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- ⚫ `toolkit test`
- ⚫ `toolkit test stdlib`
# After Submitting
```
$nothing
```
# Description
This PR bumps the rust toolchain from 1.66.1 to 1.67.1
# 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 -A
clippy::needless_collect` to check that you're using the standard code
style
- `cargo test --workspace` to check that all tests pass
- `cargo run -- crates/nu-std/tests/run.nu` 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.
-->
Move test runner to standard library.
Originated from #8819
# After Submitting
I'll update the documentation about testing:
http://www.nushell.sh/book/testing.html
---------
Co-authored-by: Mate Farkas <Mate.Farkas@oneidentity.com>
# Description
As another life improvement (and to avoid those `run cargo fmt` commits
😉), this PR adds a command to the toolkit for formatting and running
`clippy` when committing and pushing.
Thanks to @amtoine for the idea!
---------
Co-authored-by: Darren Schroeder <343840+fdncred@users.noreply.github.com>
# Description
as we now have a prelude thanks to #8627, i'd like to work on the
structure of the library 😋
and i think the first step is to make it a true standalone crate 😏
this PR
- moves all the library from `crates/nu-utils/standard_library/` to
`crates/nu-std/`
- moves the `rust` loading code from `src/run.rs` to
`crates/nu-std/src/lib.rs`
Related to #8525.
# Description
With #8525, the tests for the standard library have been enabled in the
CI.
The only places where these tests are missing are
- the PR template
- the toolkit
This PR adds
- `cargo run -- crates/nu-utils/standard_library/tests.nu` to the PR
template
- the same command as `toolkit test stdlib`
- the `test stdlib` command to `toolkit check pr`
# User-Facing Changes
```
$nothing
```
# Tests + Formatting
the new output of `toolkit check pr`, with the same color code:
> - 🟢 `toolkit fmt`
> - 🟢 `toolkit clippy`
> - 🟢 `toolkit test`
> - 🟢 `toolkit test stdlib`
# After Submitting
```
$nothing
```
when i write a PR, i run the tests and i like to have a pretty output to
make extra clear which one of the tests did run, which one did not, etc,
etc...
this always end up a variation of the template
> - `cargo fmt --all -- --check` to check standard code formatting
(`cargo fmt --all` applies these changes)
> - `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A
clippy::needless_collect` to check that you're using the standard code
style
> - `cargo test --workspace` to check that all tests pass
but with emojis and without the descriptions
> - 🟢 `cargo fmt --all`
> - 🔴 `cargo clippy --workspace -- -D warnings -D
clippy::unwrap_used -A clippy::needless_collect`
> - 🟡 `cargo test --workspace`
>
> and a ⚫ (`⚫`) when i did not have the time
or the resources to run the check stage
in this PR, i came up with a way to do that automatically with the
`toolkit` introduced in #8152😋
# Description
this PR
- adds `toolkit::pretty-print-command` to print the command names being
run with backticks and some colors
- adds `toolkit::report` to return a "report" of the PR check stages =>
see `help toolkit check pr`
- adds the `--pretty` option to `toolkit check pr` to return a
list-with-emojis version of the check report, i.e. a *GitHub*-friendly
list to drop in place in the "Tests + Formatting" section
- adds a clear mention to `toolkit check pr --pretty` in the PR template
to make it easily visible to anyone
hope you'll like it, that's not a huge deal but that's my attempt to
encourage developers to show that they run the tests, what stages did
pass and which one did not 😌👋
# User-Facing Changes
the developer can now use `toolkit check pr --pretty` to have a
ready-to-use output for *GitHub*
# Tests + Formatting
```
$nothing
```
# After Submitting
```
$nothing
```
i was writing #8148 and came to the "_Test + Formatting_" section of the
PR template.
i felt the developer instructions could be wrapped up in a common easy
to use format, e.g. a `Makefile`, to be used with a few-words command
only, e.g. `make fmt` or `make clippy`, instead of the long commands in
the PR template 🤔
> **Note**
> in case you guys do not want to add a `Makefile` to the `nushell`
source, that PR can be discarded 😌
# Description
this PR
- adds the few rules from the PR template to a new `Makefile`
- replaces the instructions in the PR template from the full commands to
the new `make` rules
# User-Facing Changes
- _none for the regular user_
- i believe easier to test PRs for the developer, allowing one not to
realy on knowing the long commands or using the shell history to run
them again 😋
# Tests + Formatting
_nothing to test_
# After Submitting
maybe mention that in `CONTRIBUTING.md`?
