-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
last, skip, drop, take until, take while, skip until, skip while, where, reverse, shuffle, append, prepend and sort-by raise error when given non-lists #7623
Conversation
#[error("Pipeline mismatch.")] | ||
#[diagnostic(code(nu::shell::pipeline_mismatch), url(docsrs))] | ||
#[error("Only supports for specific types.")] | ||
#[diagnostic(code(nu::shell::only_supports_this_input_type), url(docsrs))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The #[diagnostic]
trait creates a doc link, but only_supports_this_input_type
isn't in the docs, is it? Maybe go over there and add it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine, that will be added when the next version of nushell is published
Thank you for the PR! I noticed that after this change, PATH configuration in my
The problem was that I had some lines like this: let-env PATH = ($env.PATH | append '/some/path') Instead of this: let-env PATH = ($env.PATH | split row (char esep) | append '/some/path' ) We still recommend the former approach in the docs, so I believe many users will be impacted by this. Not sure what the right approach is, but at a minimum we should update the docs and mention this prominently in the release post. |
A tiny follow-up from #7623, changes "Only supports for specific input types" to "Input type not supported" Before: ``` 〉"asdf" | append "foo" Error: nu::shell::only_supports_this_input_type (link) × Only supports for specific input types. ╭─[entry #2:1:1] 1 │ "asdf" | append "foo" · ───┬── ───┬── · │ ╰── only list, binary, raw data or range input data is supported · ╰── input type: string ╰──── ``` After: ``` 〉"asdf" | append "foo" Error: nu:🐚:only_supports_this_input_type (link) × Input type not supported. ╭─[entry #2:1:1] 1 │ "asdf" | append "foo" · ───┬── ───┬── · │ ╰── only list, binary, raw data or range input data is supported · ╰── input type: string ╰──── ```
@rgwood |
Hmm... Should we revert the pr or make |
@WindSoilder, Nah. I don't think so. But we do need to say something in the change log with an example like I gave in the status-update discord channel. |
|
Yeah that should not be how path handling in nushell is done. Either we provide special path handling sugar for such a common usecase or we have to get some escape hatch back. |
I think it's different than we're used to but, IMO, now that I've thought about it, it's more accurate since the path env var is just a string at this point, you should have to split it before appending/prepending. Having said that, I'm not against some easier way to do it. It's always been a bit kludgy to me to update the path this way. Ideas:
|
|
Butterfly meme is this operator overloading? |
@rgwood does your option |
Neither - I was thinking the user puts |
Ok. Understood. I think that means that users put it in |
You can also do
That being said, I've been thinking the ENV_CONVERSION system is not particularly elegant and actually not used much except a couple of cases (PATH, but I use it also for LD_LIBRARY_PATH and similar delimited env vars). Maybe there is a better way to handle all of this. |
Interesting. I find it confusing that ENV_CONVERSIONS are created in env.nu but only done after config.nu. |
I would vote to temporarily revert the change for |
Yeah I agree with that |
# Description #7623 causes a break on PATH convertion, this pr is going to revert `prepend` and `append` bahavior. # 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` 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.
Any news about this? Personally, I've been thinking that for something as fundamental as PATH/Path, the default ENV_CONVERSIONS should be baked into the Nushell executable as defaults used whenever ENV_CONVERSIONS is unset, and an explicit ENV_CONVERSIONS setting (like in the default env.nu) can override it, similar to how various color_config options have overrideable defaults. |
Yeah, we're currently looking into refactoring the config system, including PATH and ENV_CONVERSIONS handling to make it more predictable and user-friendly. |
Description
Closes: #6941
About the change
It seems that all these command need to check if input is a list, to avoid duplicate code, make a new method called
into_iter_strict
inPipelineData
, so we just need to change frominto_iter
tointo_iter_restrict
.It's slightly different to #7123, which has less overhead(especially if the input type is Binary), but I think it's ok because we have less code
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 stylecargo test --workspace
to check that all tests passAfter Submitting
If your PR had any user-facing changes, update the documentation after the PR is merged, if necessary. This will help us keep the docs up to date.