# Description
#11492 fixed flags for builtin commands but I missed that plugins don't
use the same `has_flag` that builtins do. This PR addresses this.
Unfortunately this means that return value of `has_flag` needs to change
from `bool` to `Result<bool, ShellError>` to produce an error when
explicit value is not a boolean (just like in case of `has_flag` for
builtin commands. It is not possible to check this in
`EvaluatedCall::try_from_call` because
# User-Facing Changes
Passing explicit values to flags of plugin commands (like `--flag=true`
`--flag=false`) should work now.
BREAKING: changed return value of `EvaluatedCall::has_flag` method from
`bool` to `Result<bool, ShellError>`
# Tests + Formatting
Added tests and updated documentation and examples
# Description
This PR is just a minor development improvement. While working on
another feature, I noticed that the root crate lists the super useful
`pretty_assertions` in the root crate but doesn't use it in most tests.
With this change `pretty_assertions::assert_eq!` is used instead of
`core::assert_eq!` for better diffs when debugging the tests.
I thought of adding the dependency to other crates but I decided not to
since I didn't want a huge disruptive PR :)
* Updated nu_with_plugins to handle new nushell
- Now it requires the plugin format and name to be passed in, because
we can't really guess the format
- It calls `register` with format and plugin path
- It creates a temporary folder and in it an empty temporary plugin.nu
so that the tests don't conflict with each other or with local copy of
plugin.nu
- Instead of passing the commands via stdin it passes them via the new
--commands command line argument
* Rename path to command for clarity
* Enable core_inc tests
Remove deprecated inc feature and replace with new plugin feature
* Update core_inc tests for new nu_with_plugins syntax
* Rework core_inc::can_only_apply_one
The new inc plugin doesn't error if passed more than one but instead
chooses the highest increment
* Gate all plugin tests behind feature = "plugin" instead of one by one
* Remove format!-like behavior from nu_with_plugins
nu_with_plugins had format!-like behavior where it would allow calls
such as this:
```rs
nu_with_plugins!(
cwd: "dir/",
"open {} | get {}",
"Cargo.toml",
"package.version"
)
```
And although nifty it seems to have never been used before and the same
can be achieved with a format! like so:
```rs
nu_with_plugins!(
cwd: "dir/",
format!("open {} | get {}", "Cargo.toml", "package.version")
)
```
So I am removing it to keep the complexity of the macro in check
* Add multi-plugin support to nu_with_plugins
Useful for testing interactions between plugins
* Alternative 1: run `cargo build` inside of tests
* Handle Windows by canonicalizing paths and add .exe
One VM install later and lots of learning about how command line
arguments work and here we are
We introduce the `plugin` nu sub command (`nu plugin`) with basic plugin
loading support. We can choose to load plugins from a directory. Originally
introduced to make integration tests faster (by not loading any plugins on startup at all)
but `nu plugin --load some_path ; test_pipeline_that_uses_plugins_just_loaded` does not see it.
Therefore, a `nu_with_plugins!` macro for tests was introduced on top of nu`s `--skip-plugins`
switch executable which is set to true when running the integration tests that use the `nu!` macro now..
* typo fixes
* Change signature to take in short-hand flags
* update help information
* Parse short-hand flags as their long counterparts
* lints
* Modified a couple tests to use shorthand flags
