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

137 lines
4.5 KiB
Rust
Raw Normal View History

use crate::util::eval_source;
#[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 18:29:19 +00:00
use nu_path::canonicalize_with;
use nu_protocol::{
engine::{EngineState, Stack, StateWorkingSet},
report_error, 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 20:28:59 +00: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 20:28:59 +00: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 18:29:19 +00: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 20:28:59 +00: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 18:29:19 +00: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 20:28:59 +00: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 20:28:59 +00: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 20:28:59 +00: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 18:29:19 +00:00
pub fn add_plugin_file(
engine_state: &mut EngineState,
plugin_file: Option<Spanned<String>>,
storage_path: &str,
) {
Canonicalize default-config-dir and plugin-path (#11999) <!-- 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 <!-- 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. --> This PR makes sure `$nu.default-config-dir` and `$nu.plugin-path` are canonicalized. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> `$nu.default-config-dir` (and `$nu.plugin-path`) will now give canonical paths, with symlinks and whatnot resolved. # 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` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `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 > ``` --> I've added a couple of tests to check that even if the config folder and/or any of the config files within are symlinks, the `$nu.*` variables are properly canonicalized. These tests unfortunately only run on Linux and MacOS, because I couldn't figure out how to change the config directory on Windows. Also, given that they involve creating files, I'm not sure if they're excessive, so I could remove one or two of them. # 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. -->
2024-03-02 17:15:31 +00:00
let working_set = StateWorkingSet::new(engine_state);
let cwd = working_set.get_cwd();
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 18:29:19 +00:00
Canonicalize default-config-dir and plugin-path (#11999) <!-- 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 <!-- 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. --> This PR makes sure `$nu.default-config-dir` and `$nu.plugin-path` are canonicalized. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> `$nu.default-config-dir` (and `$nu.plugin-path`) will now give canonical paths, with symlinks and whatnot resolved. # 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` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `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 > ``` --> I've added a couple of tests to check that even if the config folder and/or any of the config files within are symlinks, the `$nu.*` variables are properly canonicalized. These tests unfortunately only run on Linux and MacOS, because I couldn't figure out how to change the config directory on Windows. Also, given that they involve creating files, I'm not sure if they're excessive, so I could remove one or two of them. # 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. -->
2024-03-02 17:15:31 +00:00
if let Some(plugin_file) = plugin_file {
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 18:29:19 +00:00
}
} else if let Some(mut plugin_path) = nu_path::config_dir() {
// Path to store plugins signatures
plugin_path.push(storage_path);
Canonicalize each component of config files (#12167) <!-- 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 <!-- 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. --> Because `std::fs::canonicalize` requires the path to exist, this PR makes it so that when canonicalizing any config file, the `$nu.default-config-dir/nushell` part is canonicalized first, then `$nu.default-config-dir/nushell/foo.nu` is canonicalized. This should also fix the issue @devyn pointed out [here](https://github.com/nushell/nushell/pull/12118#issuecomment-1989546708) where a couple of the tests failed if one's `~/.config/nushell` folder was actually a symlink to a different folder. The tests previously didn't canonicalize the expected paths. I was going to make a PR that caches the config directory on startup (as suggested by fdncred and Ian in Discord), but I can make that part of this PR if we want to avoid creating unnecessary PRs. I think it probably makes more sense to separate them though. # 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` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `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. -->
2024-03-13 11:26:06 +00:00
let mut plugin_path = canonicalize_with(&plugin_path, &cwd).unwrap_or(plugin_path);
plugin_path.push(PLUGIN_FILE);
Canonicalize each component of config files (#12167) <!-- 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 <!-- 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. --> Because `std::fs::canonicalize` requires the path to exist, this PR makes it so that when canonicalizing any config file, the `$nu.default-config-dir/nushell` part is canonicalized first, then `$nu.default-config-dir/nushell/foo.nu` is canonicalized. This should also fix the issue @devyn pointed out [here](https://github.com/nushell/nushell/pull/12118#issuecomment-1989546708) where a couple of the tests failed if one's `~/.config/nushell` folder was actually a symlink to a different folder. The tests previously didn't canonicalize the expected paths. I was going to make a PR that caches the config directory on startup (as suggested by fdncred and Ian in Discord), but I can make that part of this PR if we want to avoid creating unnecessary PRs. I think it probably makes more sense to separate them though. # 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` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `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. -->
2024-03-13 11:26:06 +00:00
let plugin_path = canonicalize_with(&plugin_path, &cwd).unwrap_or(plugin_path);
engine_state.plugin_signatures = Some(plugin_path);
}
}
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) {
Ensure `currently_parsed_cwd` is set for config files (#12338) <!-- 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 <!-- 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. --> Fixes #7849, #11465 based on @kubouch's suggestion in https://github.com/nushell/nushell/issues/11465#issuecomment-1883847806. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Can source files relative to `env.nu` or `config.nu` like in #6150. # 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` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `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 > ``` --> Adds test that previously failed. # 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. -->
2024-04-09 14:06:41 +00:00
// Change currently parsed directory
let prev_currently_parsed_cwd = engine_state.currently_parsed_cwd.clone();
engine_state.start_in_file(Some(&config_filename));
eval_source(
engine_state,
stack,
&contents,
&config_filename,
PipelineData::empty(),
false,
);
Ensure `currently_parsed_cwd` is set for config files (#12338) <!-- 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 <!-- 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. --> Fixes #7849, #11465 based on @kubouch's suggestion in https://github.com/nushell/nushell/issues/11465#issuecomment-1883847806. # User-Facing Changes <!-- List of all changes that impact the user experience here. This helps us keep track of breaking changes. --> Can source files relative to `env.nu` or `config.nu` like in #6150. # 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` to check that you're using the standard code style - `cargo test --workspace` to check that all tests pass (on Windows make sure to [enable developer mode](https://learn.microsoft.com/en-us/windows/apps/get-started/developer-mode-features-and-debugging)) - `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 > ``` --> Adds test that previously failed. # 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. -->
2024-04-09 14:06:41 +00:00
// Restore the currently parsed directory back
engine_state.currently_parsed_cwd = prev_currently_parsed_cwd;
// 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
})
}