Skip to content

Conversation

travishathaway
Copy link
Contributor

@travishathaway travishathaway commented Jun 16, 2025

Description

Closes: #14934

Checklist - did you ...

  • Add a file to the news directory (using the template) for the next release's release notes?
  • Add / update necessary tests?
  • Add / update outdated documentation?

@travishathaway travishathaway requested a review from a team as a code owner June 16, 2025 14:01
@github-project-automation github-project-automation bot moved this to 🆕 New in 🔎 Review Jun 16, 2025
@conda-bot conda-bot added the cla-signed [bot] added once the contributor has signed the CLA label Jun 16, 2025
Copy link

codspeed-hq bot commented Jun 16, 2025

CodSpeed Performance Report

Merging #14942 will not alter performance

Comparing travishathaway:issue-14934 (bce9398) with main (ea5728d)

Summary

✅ 21 untouched benchmarks

Co-authored-by: jaimergp <jaimergp@users.noreply.github.com>
@travishathaway travishathaway requested a review from jaimergp June 16, 2025 14:19
Copy link
Contributor

@ForgottenProgramme ForgottenProgramme left a comment

Choose a reason for hiding this comment

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

Before the envvars_force_uppercase flag was introduced, conda was by default uppercasing all the env vars. Now that the uppercasing can be switched off, the env vars created and set in activate.py are no longer uppercased automatically (when this flag is set to False) and that causes the reported bug.

I think this PR adds a suitable fix for this bug. 👍🏼

You also parametrized all the existing tests to ensure they pass in both cases:

  1. envvars_force_uppercase is set to True.
  2. envvars_force_uppercase is set to False

@github-project-automation github-project-automation bot moved this from 🆕 New to ✅ Approved in 🔎 Review Jun 16, 2025
@jezdez
Copy link
Member

jezdez commented Jun 17, 2025

@travishathaway Like we spoke earlier, here's a proposed integration test: travishathaway#4

"""Safely get environment variable, handling different shell behaviors."""
try:
value = sh.get_env_var(varname, "")
value = None if "Undefined variable" in value else value
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Special exception for csh and tcsh.

@travishathaway
Copy link
Contributor Author

@jezdez,

Thanks for those suggestions! I didn't realize we had such nice classes setup already for shell integration tests 🫶.

I basically plucked the changes you made and committed them directly to this branch. I had to make a couple updates because of some failing tests, so it would be worth it for your take a another look.

@travishathaway travishathaway requested review from jezdez June 18, 2025 06:49
@travishathaway
Copy link
Contributor Author

@jezdez,

I saw some timeout issues in the test runners 😦. I bumped the timeout up to 60 seconds. If this doesn't work, we might have to rethink our approach here or further debug why the tests are taking so long.

@travishathaway
Copy link
Contributor Author

Timeout issues are continuing to happen even after bumping it up to 60 seconds 😭. I'm not sure if bumping this up to a very high number is practical given it would probably significantly increase the time our tests need to complete.

@travishathaway
Copy link
Contributor Author

Looks like it's only happening for xonsh, fish and powershell.

@jezdez
Copy link
Member

jezdez commented Jun 18, 2025

Let's remove those tests then

@travishathaway
Copy link
Contributor Author

@jezdez,

Reset the pull request to the way it originally was but kept your additional change regarding unsetting environment variables.

unset_vars.append(env_var)
# Apply case conversion for environment variables that need to be unset
if context.envvars_force_uppercase:
unset_vars.append(env_var.upper())
Copy link
Contributor

Choose a reason for hiding this comment

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

if envvars_force_uppercase is set to true, why do we need to .upper()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We do that here to ensure it's uppercase. When the envvars_force_uppercase is True everything has to be uppercase. When it's False, we allow the variable's case to be whatever the user has designated.

@travishathaway travishathaway merged commit eacc4c4 into conda:main Jun 24, 2025
75 checks passed
@github-project-automation github-project-automation bot moved this from ✅ Approved to 🏁 Done in 🔎 Review Jun 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed [bot] added once the contributor has signed the CLA
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Setting envvars_force_uppercase to false lowercases other environment variables
5 participants