Skip to content
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

Run ENV_CONVERSIONS whenever it's modified #14591

Merged
merged 6 commits into from
Dec 25, 2024

Conversation

Bahex
Copy link
Contributor

@Bahex Bahex commented Dec 15, 2024

Description

Makes updates to $env.ENV_CONVERSIONS take effect immediately.

User-Facing Changes

No breaking change, $env.ENV_CONVERSIONS can be set and its effect used in the same file.

Tests + Formatting

  • 🟢 toolkit fmt
  • 🟢 toolkit clippy
  • 🟢 toolkit test
  • 🟢 toolkit test stdlib

After Submitting

N/A

) -> Result<(), ShellError> {
let conversions = conversions.as_record()?;
for (key, conversion) in conversions.into_iter() {
if let Some(val) = stack.get_env_var_insensitive(engine_state, key) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not objecting to this but I'm wondering if all these should be insensitive. I know Path should but I'm not sure if there's any harm having all of them case insensitive. Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I chose to make it insensitive to make it consistent with how Instruction::LoadEnv loads environment variables.

if let Some(value) = get_env_var_case_insensitive(ctx, key) {

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

People complaining about http_proxy and HTTP_PROXY is really why I was asking. Leaving it this way at least is not a breaking change. Thanks.

@NotTheDr01ds
Copy link
Contributor

Thoughts on landing this before or after 0.101? I'm personally leaning towards after to give this one more time to dogfood, but if folks feel it can go in now, I'm okay with that, too.

@fdncred
Copy link
Collaborator

fdncred commented Dec 17, 2024

I'm on the fence. I could be talked into waiting or landing (once the ci is green again).

@Bahex
Copy link
Contributor Author

Bahex commented Dec 20, 2024

I feel like the implementation can (and should) be refined but the core of the approach (hooking into the IR evaluation) is solid.

I'm personally in favor of landing it as soon as possible because the current behavior is really unintuitive, where you either

  • need 2 files because the conversion can't be utilized in the same file
  • or you need to manually convert the variable anyway even though you just defined it in ENV_CONVERSIONS

If any issues come up it can just be reverted before the release.

@fdncred
Copy link
Collaborator

fdncred commented Dec 20, 2024

@Bahex i think we're too close to the release to land this. I think we're going to try and release sunday.

@Bahex Bahex force-pushed the env_conversion_on_access branch from de6ea84 to 5d558d1 Compare December 24, 2024 15:53
@WindSoilder WindSoilder merged commit 1b01598 into nushell:main Dec 25, 2024
14 checks passed
@github-actions github-actions bot added this to the v0.102.0 milestone Dec 25, 2024
@NotTheDr01ds
Copy link
Contributor

@Bahex I'm working on getting rid of the older calls, and I noticed that the Overlay logic here doesn't seem to be present in your convert_env_vars(). I'm not noticing any difference in how conversions behave with or without that -- Do we think the new code path is okay without checking for the overlay?

@Bahex
Copy link
Contributor Author

Bahex commented Dec 27, 2024

@NotTheDr01ds Stack::get_env_var, Stack::get_env_var_insensitive and Stack::add_env_var handle the overlay logic internally as far as I can tell.

@NotTheDr01ds
Copy link
Contributor

NotTheDr01ds commented Dec 27, 2024

@Bahex Thanks! I also just noticed that convert_env_values() probably needs to account for overlays since it is running through all the environment variables, rather than just the ones in the conversions record.

Yours is more focused and just deals with the variables in the record, it seems.

fdncred pushed a commit that referenced this pull request Jan 2, 2025
# Description

Takes advantage of #14591 to remove the now-necessary calls to
`convert_env_values()` that I added in #14249. The function is now just
called once to convert `PATH`.

Also removed the Windows-build-time checks for `ensure_path`, since
previous case-insensitivity fixes make this unnecessary as well.

# User-Facing Changes

None - #14591 now handles conversion 'on-demand'.

# Tests + Formatting

- 🟢 `toolkit fmt`
- 🟢 `toolkit clippy`
- 🟢 `toolkit test`
- 🟢 `toolkit test stdlib`

# After Submitting

N/A
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Have $env.ENV_CONVERSIONS changes take place immediately
5 participants