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

Add support for detecting $VIRTUAL_ENV #181

Merged
merged 3 commits into from
Feb 19, 2025

Conversation

pantheraleo-7
Copy link
Contributor

@pantheraleo-7 pantheraleo-7 commented Dec 15, 2024

Addresses #180

(this is me writing rust for the first time 😬)

@pantheraleo-7
Copy link
Contributor Author

@microsoft-github-policy-service agree

Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

PR Overview

This pull request adds support for detecting and including the “VIRTUAL_ENV” environment variable path when listing global virtual environment directories.

  • Introduces a new parameter (virtual_env_env_var) to the list_global_virtual_envs_paths function.
  • Checks and appends the detected path for “VIRTUAL_ENV” if it exists.
  • Calls the updated function in find.rs to pass environment.get_env_var("VIRTUAL_ENV").

Changes

File Description
crates/pet-global-virtualenvs/src/lib.rs Adds a new optional parameter to handle the “VIRTUAL_ENV” variable
crates/pet/src/find.rs Passes the “VIRTUAL_ENV” environment variable to the updated function

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

Tip: Copilot only keeps its highest confidence comments to reduce noise and keep you focused. Learn more

@vs-code-engineering vs-code-engineering bot added this to the February 2025 milestone Feb 13, 2025
@karthiknadig
Copy link
Member

karthiknadig commented Feb 13, 2025

@pantheraleo-7 Looks like one of the tests is failing would it be possible for you to take a look?

@pantheraleo-7
Copy link
Contributor Author

pantheraleo-7 commented Feb 16, 2025

resolve_environment (for verify_we_can_get_same_env_info_using_resolve_with_exe) and get_python_interpreter_info (for verify_validity_of_interpreter_info) are returning ubuntu python instead of pyenv's, leading to version mismatches (3.12.9.final.0 instead of 3.12.8).

@DonJayamanne
Copy link
Collaborator

ent (for verify_we_can_get_same_env_info_using_resolve_with_exe) and get_python_interpreter_info (for verify_validity_of_interpreter_info) are returning ubuntu python instead of

Let me have a look

@DonJayamanne
Copy link
Collaborator

DonJayamanne commented Feb 17, 2025

2025-02-13T16:06:26.8530757Z [2025-02-13T16:06:26Z TRACE pet_python_utils::env] Executed Python "/home/runner/.pyenv/versions/3.12.8/bin/python" in Ok(197.539926ms) & produced an output "093385e9-59f7-4a16-a604-14bf206256fe\n{"version": "3.12.9.final.0", "sys_prefix": "/home/runner/.pyenv/versions/3.12.8", "executable": "/home/runner/.pyenv/versions/3.12.8/bin/python", "is64_bit": true}"

Unfortunately the problem is with pyenv in ubuntu CI container.
As you can see above when we launch the pyenv version of Python, we get 3.12.9.
The version of Python installed using pyenv was 3.12.8, however the run time installed is 3.12.9 even though the files are named 3.12.9. I think this is a problem with the container and it always installs the latest version of Python even when we give the exact version 3.12.8.

I have a fix for this #192

@karthiknadig karthiknadig added the feature-request Request for new features or functionality label Feb 18, 2025
@DonJayamanne DonJayamanne merged commit f586845 into microsoft:main Feb 19, 2025
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Request for new features or functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants