You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add VenvUv support and alwaysUseUv setting to control UV usage for virtual environments (#940)
## Overview
This PR implements support for UV-created virtual environments and adds
a new setting to control when UV is used for managing virtual
environments, as requested in the issue.
## Changes
### 1. New Environment Kind: `VenvUv`
Added `venvUv = 'Uv'` to the `NativePythonEnvironmentKind` enum to
represent virtual environments created with UV. This tag comes from
PET's native locator when it detects `uv_version` in the `pyvenv.cfg`
file.
### 2. New Setting: `python-envs.alwaysUseUv`
```json
{
"python-envs.alwaysUseUv": {
"type": "boolean",
"default": true,
"scope": "machine",
"description": "When set to true, uv will be used to manage all virtual environments if available. When set to false, uv will only manage virtual environments explicitly created by uv."
}
}
```
### 3. Smart UV Detection Logic
Introduced a `shouldUseUv()` helper function that determines when to use
UV:
- **VenvUv environments**: Always use UV (if installed), regardless of
the setting
- **Other environments**: Use UV only if `alwaysUseUv` setting is `true`
(if installed)
This ensures that UV-created environments always use UV for management,
while giving users control over whether UV should manage standard venvs.
### 4. Updated Operations
All virtual environment and pip operations now respect the new setting:
- **Environment Discovery**: `findVirtualEnvironments()` and
`resolveVenvPythonEnvironmentPath()` now handle both `Venv` and `Uv`
kinds
- **Environment Creation**: `createWithProgress()` uses the setting to
decide between `uv venv` and `python -m venv`
- **Package Management**: `refreshPipPackagesRaw()` and
`managePackages()` use the setting to decide between `uv pip` and
`python -m pip`
## Behavior
| Environment Type | alwaysUseUv = true | alwaysUseUv = false |
|-----------------|-------------------|---------------------|
| VenvUv (UV-created) | ✅ Use UV | ✅ Use UV |
| Venv (standard) | ✅ Use UV | ❌ Don't use UV |
---------
Co-authored-by: copilot-swe-agent[bot] <[email protected]>
Co-authored-by: eleanorjboyd <[email protected]>
- Over-complex mocks → Minimal mocks with only needed methods
552
+
- Brittle assertions → Behavior-focused with error messages
553
+
- Vague test names → Clear scenario descriptions
554
+
- Missing structure → Mock → Run → Assert pattern
555
+
540
556
## 🧠 Agent Learnings
541
557
542
558
- Always use dynamic path construction with Node.js `path` module when testing functions that resolve paths against workspace folders to ensure cross-platform compatibility (1)
@@ -551,3 +567,7 @@ envConfig.inspect
551
567
- When a targeted test run yields 0 tests, first verify the compiled JS exists under `out/test` (rootDir is `src`); absence almost always means the test file sits outside `src` or compilation hasn't run yet (1)
552
568
- When unit tests fail with VS Code API errors like `TypeError: X is not a constructor` or `Cannot read properties of undefined (reading 'Y')`, check if VS Code APIs are properly mocked in `/src/test/unittests.ts` - add missing Task-related APIs (`Task`, `TaskScope`, `ShellExecution`, `TaskRevealKind`, `TaskPanelKind`) and namespace mocks (`tasks`) following the existing pattern of `mockedVSCode.X = vscodeMocks.vscMockExtHostedTypes.X` (1)
553
569
- Create minimal mock objects with only required methods and use TypeScript type assertions (e.g., mockApi as PythonEnvironmentApi) to satisfy interface requirements instead of implementing all interface methods when only specific methods are needed for the test (1)
570
+
- When reviewing existing tests, focus on behavior rather than implementation details in test names and assertions - transform "should return X when Y" into "should [expected behavior] when [scenario context]" (1)
571
+
- Simplify mock setup by only mocking methods actually used in tests and use `as unknown as Type` for TypeScript compatibility (1)
572
+
- When testing async functions that use child processes, call the function first to get a promise, then use setTimeout to emit mock events, then await the promise - this ensures proper timing of mock setup versus function execution (1)
573
+
- Cannot stub internal function calls within the same module after import - stub external dependencies instead (e.g., stub `childProcessApis.spawnProcess` rather than trying to stub `helpers.isUvInstalled` when testing `helpers.shouldUseUv`) because intra-module calls use direct references, not module exports (1)
"python-envs.revealProjectInExplorer.title": "Reveal Project in Explorer",
42
-
"python-envs.runPetInTerminal.title": "Run Python Environment Tool (PET) in Terminal..."
42
+
"python-envs.runPetInTerminal.title": "Run Python Environment Tool (PET) in Terminal...",
43
+
"python-envs.alwaysUseUv.description": "When set to true, uv will be used to manage all virtual environments if available. When set to false, uv will only manage virtual environments explicitly created by uv."
* @param envPath - Optional environment path to check against UV environments list
41
+
* @returns True if uv should be used, false otherwise. For UV environments, returns true if uv is installed. For other environments, checks the 'python-envs.alwaysUseUv' setting and uv availability.
0 commit comments