Add POETRY_VIRTUALENVS_IN_PROJECT environment variable support

[Copilot]

• Revert unrelated package-lock.json changes
• Make isPoetryVirtualenvsInProject() accept optional parameter for testability
• Restructure as guard clause to eliminate redundant assignment
• Export nativeToPythonEnv for testability
• Add integration tests for nativeToPythonEnv env var classification behavior (5 tests)
• Add process.env fallback test for isPoetryVirtualenvsInProject
• All 595 tests passing (15 poetry-specific)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Poetry: Missing support for POETRY_VIRTUALENVS_IN_PROJECT environment variable</issue_title>
<issue_description>## Problem

The extension does not honor the POETRY_VIRTUALENVS_IN_PROJECT environment variable when determining whether a .venv directory in a project should be treated as a Poetry environment.

Expected Behavior

When POETRY_VIRTUALENVS_IN_PROJECT=true (or 1) is set, Poetry creates virtualenvs in the project's .venv directory. The extension should recognize these as Poetry environments.

Current Behavior

The extension doesn't check this environment variable, so .venv directories in Poetry projects may not be correctly identified as Poetry environments.

PET Server Reference

The PET server properly handles this in pet-poetry/src/env_variables.rs:

poetry_virtualenvs_in_project: env
    .get_env_var("POETRY_VIRTUALENVS_IN_PROJECT".to_string())
    .map(|v| v == "1" || v.to_lowercase() == "true"),

And in pet-poetry/src/environment_locations.rs:

fn should_use_local_venv_as_poetry_env(
    global: &Option<Config>,
    local: &Option<Config>,
    env: &EnvVariables,
) -> bool {
    // Given preference to env variable.
    if let Some(poetry_virtualenvs_in_project) = env.poetry_virtualenvs_in_project {
        return poetry_virtualenvs_in_project;
    }
    // ...
}

Suggested Fix

Add support in poetryUtils.ts to:

1. Check process.env.POETRY_VIRTUALENVS_IN_PROJECT
2. Consider .venv as a Poetry env when this is set and the parent has pyproject.toml with [tool.poetry]

Related

This is similar to how poetry.toml local config with virtualenvs.in-project = true should work.

Affected File

src/managers/poetry/poetryUtils.ts</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Poetry: Missing support for POETRY_VIRTUALENVS_IN_PROJECT environment variable #1183

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[karthiknadig]

PR Review: Add POETRY_VIRTUALENVS_IN_PROJECT environment variable support

Overall: The core idea is correct and well-motivated — the extension should honor POETRY_VIRTUALENVS_IN_PROJECT to match the PET server's behavior. The isPoetryVirtualenvsInProject() function logic is clean and correct. However, several issues need addressing before merge:

Issues

1. Unrelated package-lock.json changes — The PR adds "peer": true to ~15 unrelated packages. This noise should be removed.

2. No tests for the actual behavior change — The tests only cover the isPoetryVirtualenvsInProject() helper. The real feature — how it affects environment classification in nativeToPythonEnv — is untested. This is the main risk area.

3. Redundant assignment — isGlobalPoetryEnv = false on the truthy branch re-assigns the initial value. A guard clause pattern would be cleaner and reduce nesting.

4. Testability — Direct process.env reads make the integration point hard to mock. Consider a small refactor to enable testing the nativeToPythonEnv path.

[karthiknadig]

Re-review: All previous feedback addressed

The PR now looks much cleaner. All four issues from my previous review have been resolved:

• package-lock.json noise removed
• Guard clause restructure — no more redundant isGlobalPoetryEnv = false
• isPoetryVirtualenvsInProject accepts optional parameter — enables testing without process.env manipulation for most cases
• Integration tests added — 5 tests covering env var + project combinations in nativeToPythonEnv

Remaining minor observations (non-blocking)

1. Hardcoded POSIX paths in tests — works but slightly inconsistent with project conventions
2. nativeToPythonEnv export — consider marking as @internal
3. No positive POETRY_GLOBAL test — all integration tests verify group === undefined; a test confirming group === POETRY_GLOBAL for envs in the global directory would round out coverage

Overall the logic is correct, the code is clean, and the test coverage is reasonable. Approving.