nushell/crates/nu-cli/src/config_files.rs

127 lines
4.0 KiB
Rust
Raw Normal View History

use crate::util::eval_source;
use nu_command::util::report_error;
#[cfg(feature = "plugin")]
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 20:29:19 +02:00
use nu_path::canonicalize_with;
use nu_protocol::engine::{EngineState, Stack, StateWorkingSet};
use nu_protocol::{HistoryFileFormat, PipelineData};
add some startup performance metrics (#7851) # Description This PR changes the old performance logging with `Instant` timers. I'm not sure if this is the best way to do it but it does help reveal where time is being spent on startup. This is what it looks like when you launch nushell with `cargo run -- --log-level info`. I'm using the `info` log level exclusively for performance monitoring at this point. ![image](https://user-images.githubusercontent.com/343840/214372903-fdfa9c99-b846-47f3-8faf-bd6ed98df3a9.png) ## After Startup Since you're in the repl, you can continue running commands. Here's the output of `ls`, for instance. ![image](https://user-images.githubusercontent.com/343840/214373035-4d2f6e2d-5c1d-43d3-b997-51d79d496ba3.png) Note that the above screenshots are in debug mode, so they're much slower than release. # User-Facing 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 # 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-01-24 21:28:59 +01:00
#[cfg(feature = "plugin")]
use nu_protocol::{ParseError, Spanned};
#[cfg(feature = "plugin")]
add some startup performance metrics (#7851) # Description This PR changes the old performance logging with `Instant` timers. I'm not sure if this is the best way to do it but it does help reveal where time is being spent on startup. This is what it looks like when you launch nushell with `cargo run -- --log-level info`. I'm using the `info` log level exclusively for performance monitoring at this point. ![image](https://user-images.githubusercontent.com/343840/214372903-fdfa9c99-b846-47f3-8faf-bd6ed98df3a9.png) ## After Startup Since you're in the repl, you can continue running commands. Here's the output of `ls`, for instance. ![image](https://user-images.githubusercontent.com/343840/214373035-4d2f6e2d-5c1d-43d3-b997-51d79d496ba3.png) Note that the above screenshots are in debug mode, so they're much slower than release. # User-Facing 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 # 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-01-24 21:28:59 +01:00
use nu_utils::utils::perf;
use std::path::PathBuf;
#[cfg(feature = "plugin")]
const PLUGIN_FILE: &str = "plugin.nu";
const HISTORY_FILE_TXT: &str = "history.txt";
const HISTORY_FILE_SQLITE: &str = "history.sqlite3";
#[cfg(feature = "plugin")]
pub fn read_plugin_file(
engine_state: &mut EngineState,
stack: &mut Stack,
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 20:29:19 +02:00
plugin_file: Option<Spanned<String>>,
storage_path: &str,
) {
add some startup performance metrics (#7851) # Description This PR changes the old performance logging with `Instant` timers. I'm not sure if this is the best way to do it but it does help reveal where time is being spent on startup. This is what it looks like when you launch nushell with `cargo run -- --log-level info`. I'm using the `info` log level exclusively for performance monitoring at this point. ![image](https://user-images.githubusercontent.com/343840/214372903-fdfa9c99-b846-47f3-8faf-bd6ed98df3a9.png) ## After Startup Since you're in the repl, you can continue running commands. Here's the output of `ls`, for instance. ![image](https://user-images.githubusercontent.com/343840/214373035-4d2f6e2d-5c1d-43d3-b997-51d79d496ba3.png) Note that the above screenshots are in debug mode, so they're much slower than release. # User-Facing 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 # 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-01-24 21:28:59 +01:00
let start_time = std::time::Instant::now();
let mut plug_path = String::new();
// Reading signatures from signature file
// The plugin.nu file stores the parsed signature collected from each registered plugin
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 20:29:19 +02:00
add_plugin_file(engine_state, plugin_file, storage_path);
let plugin_path = engine_state.plugin_signatures.clone();
if let Some(plugin_path) = plugin_path {
let plugin_filename = plugin_path.to_string_lossy();
add some startup performance metrics (#7851) # Description This PR changes the old performance logging with `Instant` timers. I'm not sure if this is the best way to do it but it does help reveal where time is being spent on startup. This is what it looks like when you launch nushell with `cargo run -- --log-level info`. I'm using the `info` log level exclusively for performance monitoring at this point. ![image](https://user-images.githubusercontent.com/343840/214372903-fdfa9c99-b846-47f3-8faf-bd6ed98df3a9.png) ## After Startup Since you're in the repl, you can continue running commands. Here's the output of `ls`, for instance. ![image](https://user-images.githubusercontent.com/343840/214373035-4d2f6e2d-5c1d-43d3-b997-51d79d496ba3.png) Note that the above screenshots are in debug mode, so they're much slower than release. # User-Facing 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 # 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-01-24 21:28:59 +01:00
plug_path = plugin_filename.to_string();
if let Ok(contents) = std::fs::read(&plugin_path) {
eval_source(
engine_state,
stack,
&contents,
&plugin_filename,
PipelineData::empty(),
false,
);
}
}
add some startup performance metrics (#7851) # Description This PR changes the old performance logging with `Instant` timers. I'm not sure if this is the best way to do it but it does help reveal where time is being spent on startup. This is what it looks like when you launch nushell with `cargo run -- --log-level info`. I'm using the `info` log level exclusively for performance monitoring at this point. ![image](https://user-images.githubusercontent.com/343840/214372903-fdfa9c99-b846-47f3-8faf-bd6ed98df3a9.png) ## After Startup Since you're in the repl, you can continue running commands. Here's the output of `ls`, for instance. ![image](https://user-images.githubusercontent.com/343840/214373035-4d2f6e2d-5c1d-43d3-b997-51d79d496ba3.png) Note that the above screenshots are in debug mode, so they're much slower than release. # User-Facing 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 # 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-01-24 21:28:59 +01:00
perf(
&format!("read_plugin_file {}", &plug_path),
start_time,
file!(),
line!(),
column!(),
engine_state.get_config().use_ansi_coloring,
add some startup performance metrics (#7851) # Description This PR changes the old performance logging with `Instant` timers. I'm not sure if this is the best way to do it but it does help reveal where time is being spent on startup. This is what it looks like when you launch nushell with `cargo run -- --log-level info`. I'm using the `info` log level exclusively for performance monitoring at this point. ![image](https://user-images.githubusercontent.com/343840/214372903-fdfa9c99-b846-47f3-8faf-bd6ed98df3a9.png) ## After Startup Since you're in the repl, you can continue running commands. Here's the output of `ls`, for instance. ![image](https://user-images.githubusercontent.com/343840/214373035-4d2f6e2d-5c1d-43d3-b997-51d79d496ba3.png) Note that the above screenshots are in debug mode, so they're much slower than release. # User-Facing 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 # 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-01-24 21:28:59 +01:00
);
}
#[cfg(feature = "plugin")]
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 20:29:19 +02:00
pub fn add_plugin_file(
engine_state: &mut EngineState,
plugin_file: Option<Spanned<String>>,
storage_path: &str,
) {
if let Some(plugin_file) = plugin_file {
let working_set = StateWorkingSet::new(engine_state);
let cwd = working_set.get_cwd();
if let Ok(path) = canonicalize_with(&plugin_file.item, cwd) {
engine_state.plugin_signatures = Some(path)
} else {
let e = ParseError::FileNotFound(plugin_file.item, plugin_file.span);
report_error(&working_set, &e);
Add plugin CLI argument (#6064) * Add plugin CLI argument While working on supporting CustomValues in Plugins I stumbled upon the test utilities defined in [nu-test-support][nu-test-support] and thought these will come in handy, but they end up being outdated. They haven't been used or since engine-q's was merged, so they are currently using the old way engine-q handled plugins, where it would just look into a specific folder for plugins and call them without signatures or registration. While fixing that I realized that there is currently no way to tell nushell to load and save signatures into a specific path, and so those integration tests could end up potentially conflicting with each other and with the local plugins the person running them is using. So this adds a new CLI argument to specify where to store and load plugin signatures from I am not super sure of the way I implemented this, mainly I was a bit confused about the distinction between [src/config_files.rs][src/config_files.rs] and [crates/nu-cli/src/config_files.rs][crates/nu-cli/src/config_files.rs]. Should I be moving the plugin loading function from the `nu-cli` one to the root one? [nu-test-support]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-test-support/src/macros.rs#L106 [src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/src/config_files.rs [crates/nu-cli/src/config_files.rs]: https://github.com/nushell/nushell/blob/9d0be7d96fa0e960bcc702a523ca62f0c53b765c/crates/nu-cli/src/config_files.rs * Gate new CLI option behind plugin feature * Rename option to plugin-config
2022-07-17 20:29:19 +02:00
}
} else if let Some(mut plugin_path) = nu_path::config_dir() {
// Path to store plugins signatures
plugin_path.push(storage_path);
plugin_path.push(PLUGIN_FILE);
engine_state.plugin_signatures = Some(plugin_path.clone());
}
}
pub fn eval_config_contents(
config_path: PathBuf,
engine_state: &mut EngineState,
stack: &mut Stack,
) {
if config_path.exists() & config_path.is_file() {
let config_filename = config_path.to_string_lossy();
if let Ok(contents) = std::fs::read(&config_path) {
eval_source(
engine_state,
stack,
&contents,
&config_filename,
PipelineData::empty(),
false,
);
// Merge the environment in case env vars changed in the config
match nu_engine::env::current_dir(engine_state, stack) {
Ok(cwd) => {
if let Err(e) = engine_state.merge_env(stack, cwd) {
let working_set = StateWorkingSet::new(engine_state);
report_error(&working_set, &e);
}
}
Err(e) => {
let working_set = StateWorkingSet::new(engine_state);
report_error(&working_set, &e);
}
}
}
}
}
pub(crate) fn get_history_path(storage_path: &str, mode: HistoryFileFormat) -> Option<PathBuf> {
nu_path::config_dir().map(|mut history_path| {
history_path.push(storage_path);
history_path.push(match mode {
HistoryFileFormat::PlainText => HISTORY_FILE_TXT,
HistoryFileFormat::Sqlite => HISTORY_FILE_SQLITE,
});
history_path
})
}