nushell/crates/nu-test-support/src/commands.rs

62 lines
1.7 KiB
Rust
Raw Normal View History

Restore `nu_with_plugins` test macro (#6065) * 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
2022-07-22 06:14:37 +02:00
use std::{
io::Read,
process::{Command, Stdio},
sync::{
atomic::{AtomicBool, Ordering::Relaxed},
Mutex,
},
Restore `nu_with_plugins` test macro (#6065) * 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
2022-07-22 06:14:37 +02:00
};
static CARGO_BUILD_LOCK: Mutex<()> = Mutex::new(());
static PLUGINS_BUILT: AtomicBool = AtomicBool::new(false);
// This runs `cargo build --package nu_plugin_*` to ensure that all plugins
// have been built before plugin tests run. We use a lock to avoid multiple
// simultaneous `cargo build` invocations clobbering each other.
pub fn ensure_plugins_built() {
let _guard = CARGO_BUILD_LOCK.lock().expect("could not get mutex lock");
if PLUGINS_BUILT.load(Relaxed) {
return;
}
Restore `nu_with_plugins` test macro (#6065) * 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
2022-07-22 06:14:37 +02:00
let cargo_path = env!("CARGO");
let mut arguments = vec!["build", "--package", "nu_plugin_*", "--quiet"];
Restore `nu_with_plugins` test macro (#6065) * 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
2022-07-22 06:14:37 +02:00
let profile = std::env::var("NUSHELL_CARGO_TARGET");
if let Ok(profile) = &profile {
arguments.push("--profile");
arguments.push(profile);
}
let mut command = Command::new(cargo_path)
.args(arguments)
.stdout(Stdio::piped())
.stderr(Stdio::piped())
.spawn()
.expect("Failed to spawn cargo build command");
let stderr = command.stderr.take();
let success = command
.wait()
.expect("failed to wait cargo build command")
.success();
if let Some(mut stderr) = stderr {
let mut buffer = String::new();
stderr
.read_to_string(&mut buffer)
.expect("failed to read cargo build stderr");
if !buffer.is_empty() {
println!("=== cargo build stderr\n{buffer}");
Restore `nu_with_plugins` test macro (#6065) * 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
2022-07-22 06:14:37 +02:00
}
}
if !success {
panic!("cargo build failed");
}
PLUGINS_BUILT.store(true, Relaxed);
Restore `nu_with_plugins` test macro (#6065) * 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
2022-07-22 06:14:37 +02:00
}