nushell/toolkit.nu

484 lines
15 KiB
Text
Raw Normal View History

# this module regroups a bunch of development tools to make the development
# process easier for anyone.
#
# the main purpose of `toolkit` is to offer an easy to use interface for the
# developer during a PR cycle, namely to (**1**) format the source base,
# (**2**) catch classical flaws in the new changes with *clippy* and (**3**)
# make sure all the tests pass.
# check standard code formatting and apply the changes
export def fmt [
--check # do not apply the format changes, only check the syntax
--verbose # print extra information about the command's progress
] {
if $verbose {
print $"running ('toolkit fmt' | pretty-format-command)"
}
if $check {
try {
cargo fmt --all -- --check
} catch {
error make --unspanned {
msg: $"\nplease run ('toolkit fmt' | pretty-format-command) to fix formatting!"
}
}
} else {
cargo fmt --all
}
}
# check that you're using the standard code style
#
# > it is important to make `clippy` happy :relieved:
export def clippy [
--verbose # print extra information about the command's progress
--features: list<string> # the list of features to run *Clippy* on
] {
if $verbose {
print $"running ('toolkit clippy' | pretty-format-command)"
}
# If changing these settings also change CI settings in .github/workflows/ci.yml
try {(
cargo clippy
--workspace
--exclude nu_plugin_*
--features ($features | str join ",")
--
-D warnings
-D clippy::unwrap_used
)
if $verbose {
print $"running ('toolkit clippy' | pretty-format-command) on tests"
}
# In tests we don't have to deny unwrap
(
cargo clippy
--tests
--workspace
--exclude nu_plugin_*
--features ($features | str join ",")
--
-D warnings
)
if $verbose {
print $"running ('toolkit clippy' | pretty-format-command) on plugins"
}
(
cargo clippy
--package nu_plugin_*
--
-D warnings
-D clippy::unwrap_used
)
} catch {
error make --unspanned {
msg: $"\nplease fix the above ('clippy' | pretty-format-command) errors before continuing!"
}
}
}
# check that all the tests pass
export def test [
--fast # use the "nextext" `cargo` subcommand to speed up the tests (see [`cargo-nextest`](https://nexte.st/) and [`nextest-rs/nextest`](https://github.com/nextest-rs/nextest))
--features: list<string> # the list of features to run the tests on
--workspace # run the *Clippy* command on the whole workspace (overrides `--features`)
] {
if $fast {
if $workspace {
cargo nextest run --all
} else {
cargo nextest run --features ($features | str join ",")
}
} else {
if $workspace {
cargo test --workspace
} else {
cargo test --features ($features | str join ",")
}
}
}
# run the tests for the standard library
Implement annotations support in test runner (#9406) <!-- 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. -->
2023-07-02 08:41:33 +00:00
export def "test stdlib" [
--extra-args: string = ''
] {
cargo run -- -c $"use std testing; testing run-tests --path crates/nu-std ($extra_args)"
}
# formats the pipe input inside backticks, dimmed and italic, as a pretty command
def pretty-format-command [] {
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
$"`(ansi default_dimmed)(ansi default_italic)($in)(ansi reset)`"
}
# return a report about the check stage
#
# - fmt comes first
# - then clippy
# - and finally the tests
#
# without any option, `report` will return an empty report.
# otherwise, the truth values will be incremental, following
# the order above.
def report [
--fail-fmt
--fail-clippy
--fail-test
--fail-test-stdlib
--no-fail
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
] {
[fmt clippy test "test stdlib"]
| wrap stage
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
| merge (
if $no_fail { [true true true true] }
else if $fail_fmt { [false null null null] }
else if $fail_clippy { [true false null null] }
else if $fail_test { [true true false null] }
else if $fail_test_stdlib { [true true true false] }
else { [null null null null] }
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
| wrap success
)
| upsert emoji {|it|
if ($it.success == null) {
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
":black_circle:"
} else if $it.success {
":green_circle:"
} else {
":red_circle:"
}
}
| each {|it|
$"- ($it.emoji) `toolkit ($it.stage)`"
}
| to text
}
# run all the necessary checks and tests to submit a perfect PR
#
# # Example
# let us say we apply a change that
# - breaks the formatting, e.g. with extra newlines everywhere
# - makes clippy sad, e.g. by adding unnecessary string conversions with `.to_string()`
# - breaks the tests by output bad string data from a data structure conversion
#
# > the following diff breaks all of the three checks!
# > ```diff
# > diff --git a/crates/nu-command/src/formats/to/nuon.rs b/crates/nu-command/src/formats/to/nuon.rs
# > index abe34c054..927d6a3de 100644
# > --- a/crates/nu-command/src/formats/to/nuon.rs
# > +++ b/crates/nu-command/src/formats/to/nuon.rs
# > @@ -131,7 +131,8 @@ pub fn value_to_string(v: &Value, span: Span) -> Result<String, ShellError> {
# > }
# > })
# > .collect();
# > - let headers_output = headers.join(", ");
# > + let headers_output = headers.join(&format!("x {}", "")
# > + .to_string());
# >
# > let mut table_output = vec![];
# > for val in vals {
# > ```
#
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
# > **Note**
# > at every stage, the `toolkit check pr` will return a report of the few stages being run.
#
# - we run the toolkit once and it fails...
# ```nushell
# >_ toolkit check pr
# running `toolkit fmt`
# Diff in /home/amtoine/.local/share/git/store/github.com/amtoine/nushell/crates/nu-command/src/formats/to/nuon.rs at line 131:
# }
# })
# .collect();
# - let headers_output = headers.join(&format!("x {}", "")
# - .to_string());
# + let headers_output = headers.join(&format!("x {}", "").to_string());
#
# let mut table_output = vec![];
# for val in vals {
#
# please run toolkit fmt to fix the formatting
# ```
# - we run `toolkit fmt` as proposed and rerun the toolkit... to see clippy is sad...
# ```nushell
# running `toolkit fmt`
# running `toolkit clippy`
# ...
# error: redundant clone
# --> crates/nu-command/src/formats/to/nuon.rs:134:71
# |
# 134 | let headers_output = headers.join(&format!("x {}", "").to_string());
# | ^^^^^^^^^^^^ help: remove this
# |
# note: this value is dropped without further use
# --> crates/nu-command/src/formats/to/nuon.rs:134:52
# |
# 134 | let headers_output = headers.join(&format!("x {}", "").to_string());
# | ^^^^^^^^^^^^^^^^^^^
# = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_clone
# = note: `-D clippy::redundant-clone` implied by `-D warnings`
#
# error: could not compile `nu-command` due to previous error
# ```
# - we remove the useless `.to_string()`, and in that cases, the whole format is useless, only `"x "` is useful!
# but now the tests do not pass :sob:
# ```nushell
# running `toolkit fmt`
# running `toolkit clippy`
# ...
# running `toolkit test`
# ...
# failures:
# commands::insert::insert_uses_enumerate_index
# commands::merge::multi_row_table_overwrite
# commands::merge::single_row_table_no_overwrite
# commands::merge::single_row_table_overwrite
# commands::update::update_uses_enumerate_index
# commands::upsert::upsert_uses_enumerate_index_inserting
# commands::upsert::upsert_uses_enumerate_index_updating
# commands::where_::where_uses_enumerate_index
# format_conversions::nuon::does_not_quote_strings_unnecessarily
# format_conversions::nuon::to_nuon_table
# ```
# - finally let's fix the tests by removing the `x`, essentially removing the whole diff we applied at the top!
#
# now the whole `toolkit check pr` passes! :tada:
export def "check pr" [
--fast # use the "nextext" `cargo` subcommand to speed up the tests (see [`cargo-nextest`](https://nexte.st/) and [`nextest-rs/nextest`](https://github.com/nextest-rs/nextest))
--features: list<string> # the list of features to check the current PR on
] {
remove let-env, focus on mutating $env (#9574) # 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: - :heavy_check_mark: [starship](https://github.com/starship/starship/blob/master/src/init/starship.nu) - :heavy_check_mark: [virtualenv](https://github.com/pypa/virtualenv/blob/main/src/virtualenv/activation/nushell/activate.nu) - :heavy_check_mark: [atuin](https://github.com/ellie/atuin/blob/main/atuin/src/shell/atuin.nu) (PR: https://github.com/ellie/atuin/pull/1080) - :x: [zoxide](https://github.com/ajeetdsouza/zoxide/blob/main/templates/nushell.txt) (PR: https://github.com/ajeetdsouza/zoxide/pull/587) - :heavy_check_mark: [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)
2023-06-30 19:57:51 +00:00
$env.NU_TEST_LOCALE_OVERRIDE = 'en_US.utf8';
try {
fmt --check --verbose
} catch {
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
return (report --fail-fmt)
}
try {
clippy --features $features --verbose
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
} catch {
return (report --fail-clippy)
}
print $"running ('toolkit test' | pretty-format-command)"
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
try {
if $fast {
if ($features | is-empty) {
test --workspace --fast
} else {
test --features $features --fast
}
} else {
if ($features | is-empty) {
test --workspace
} else {
test --features $features
}
}
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
} catch {
return (report --fail-test)
}
print $"running ('toolkit test stdlib' | pretty-format-command)"
try {
test stdlib
} catch {
return (report --fail-test-stdlib)
}
FEATURE: add a pretty output to `toolkit check pr` (#8416) 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 > - :green_circle: `cargo fmt --all` > - :red_circle: `cargo clippy --workspace -- -D warnings -D clippy::unwrap_used -A clippy::needless_collect` > - :yellow_circle: `cargo test --workspace` > > and a :black_circle: (`:black_circle:`) 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 :yum: # 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 :relieved: :wave: # 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 ```
2023-03-18 12:58:21 +00:00
report --no-fail
}
# run Nushell from source with a right indicator
export def run [] {
cargo run -- [
-e "$env.PROMPT_COMMAND_RIGHT = $'(ansi magenta_reverse)trying Nushell inside Cargo(ansi reset)'"
]
}
# set up git hooks to run:
# - `toolkit fmt --check --verbose` on `git commit`
# - `toolkit fmt --check --verbose` and `toolkit clippy --verbose` on `git push`
export def setup-git-hooks [] {
print "This command will change your local git configuration and hence modify your development workflow. Are you sure you want to continue? [y]"
if (input) == "y" {
print $"running ('toolkit setup-git-hooks' | pretty-format-command)"
git config --local core.hooksPath .githooks
} else {
print $"aborting ('toolkit setup-git-hooks' | pretty-format-command)"
}
}
def build-nushell [features: string] {
print $'(char nl)Building nushell'
print '----------------------------'
cargo build --features $features --locked
}
def build-plugin [] {
let plugin = $in
print $'(char nl)Building ($plugin)'
print '----------------------------'
cd $"crates/($plugin)"
cargo build
}
# build Nushell and plugins with some features
export def build [
...features: string@"nu-complete list features" # a space-separated list of feature to install with Nushell
--all # build all plugins with Nushell
] {
build-nushell ($features | str join ",")
if not $all {
return
}
let plugins = [
nu_plugin_inc,
nu_plugin_gstat,
nu_plugin_query,
nu_plugin_example,
nu_plugin_custom_values,
nu_plugin_formats,
]
for plugin in $plugins {
$plugin | build-plugin
}
}
def "nu-complete list features" [] {
open Cargo.toml | get features | transpose feature dependencies | get feature
}
enhancement(test)- complete the install command to install plugins #9342 (#9357) # 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>
2023-06-13 13:28:53 +00:00
def install-plugin [] {
let plugin = $in
print $'(char nl)Installing ($plugin)'
print '----------------------------'
cargo install --path $"crates/($plugin)"
}
# install Nushell and features you want
export def install [
...features: string@"nu-complete list features" # a space-separated list of feature to install with Nushell
--all # install all plugins with Nushell
] {
touch crates/nu-cmd-lang/build.rs # needed to make sure `version` has the correct `commit_hash`
cargo install --path . --features ($features | str join ",") --locked --force
enhancement(test)- complete the install command to install plugins #9342 (#9357) # 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>
2023-06-13 13:28:53 +00:00
if not $all {
return
}
let plugins = [
nu_plugin_inc,
nu_plugin_gstat,
nu_plugin_query,
nu_plugin_example,
nu_plugin_custom_values,
nu_plugin_formats,
]
enhancement(test)- complete the install command to install plugins #9342 (#9357) # 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>
2023-06-13 13:28:53 +00:00
for plugin in $plugins {
$plugin | install-plugin
}
}
def windows? [] {
$nu.os-info.name == windows
}
# filter out files that end in .d
def keep-plugin-executables [] {
if (windows?) { where name ends-with '.exe' } else { where name !~ '\.d' }
}
# register all installed plugins
export def "register plugins" [] {
let plugin_path = (which nu | get path.0 | path dirname)
let plugins = (ls $plugin_path | where name =~ nu_plugin | keep-plugin-executables)
if ($plugins | is-empty) {
print $"no plugins found in ($plugin_path)..."
return
}
for plugin in $plugins {
print -n $"registering ($plugin.name), "
nu -c $"register '($plugin.name)'"
print "success!"
}
print "\nplugins registered, please restart nushell"
}
def compute-coverage [] {
print "Setting up environment variables for coverage"
# Enable LLVM coverage tracking through environment variables
# show env outputs .ini/.toml style description of the variables
# In order to use from toml, we need to make sure our string literals are single quoted
# This is especially important when running on Windows since "C:\blah" is treated as an escape
cargo llvm-cov show-env | str replace (char dq) (char sq) -a | from toml | load-env
print "Cleaning up coverage data"
cargo llvm-cov clean --workspace
print "Building with workspace and profile=ci"
# Apparently we need to explicitly build the necessary parts
# using the `--profile=ci` is basically `debug` build with unnecessary symbols stripped
# leads to smaller binaries and potential savings when compiling and running
cargo build --workspace --profile=ci
print "Running tests with --workspace and profile=ci"
cargo test --workspace --profile=ci
# You need to provide the used profile to find the raw data
print "Generating coverage report as lcov.info"
cargo llvm-cov report --lcov --output-path lcov.info --profile=ci
}
# Script to generate coverage locally
#
# Output: `lcov.info` file
#
# Relies on `cargo-llvm-cov`. Install via `cargo install cargo-llvm-cov`
# https://github.com/taiki-e/cargo-llvm-cov
#
# You probably have to run `cargo llvm-cov clean` once manually,
# as you have to confirm to install additional tooling for your rustup toolchain.
# Else the script might stall waiting for your `y<ENTER>`
#
# Some of the internal tests rely on the exact cargo profile
# (This is somewhat criminal itself)
# but we have to signal to the tests that we use the `ci` `--profile`
#
# Manual gathering of coverage to catch invocation of the `nu` binary.
# This is relevant for tests using the `nu!` macro from `nu-test-support`
# see: https://github.com/taiki-e/cargo-llvm-cov#get-coverage-of-external-tests
#
# To display the coverage in your editor see:
#
# - https://marketplace.visualstudio.com/items?itemName=ryanluker.vscode-coverage-gutters
# - https://github.com/umaumax/vim-lcov
# - https://github.com/andythigpen/nvim-coverage (probably needs some additional config)
export def cov [] {
let start = (date now)
$env.NUSHELL_CARGO_PROFILE = "ci"
compute-coverage
let end = (date now)
print $"Coverage generation took ($end - $start)."
}
export def main [] { help toolkit }