feat: add pet-hatch locator for Hatch environments (Fixes #450)#460
Open
karthiknadig wants to merge 6 commits intomainfrom
Open
feat: add pet-hatch locator for Hatch environments (Fixes #450)#460karthiknadig wants to merge 6 commits intomainfrom
karthiknadig wants to merge 6 commits intomainfrom
Conversation
Adds a new pet-hatch crate that detects Hatch-managed virtual environments so they are no longer misclassified as plain Venv by downstream consumers. Implementation matches Hatch's actual storage layout from src/hatch/env/virtual.py: - Default storage: <data_dir>/env/virtual/<project_name>/<project_id>/<venv_name> (3 levels deep) - HATCH_DATA_DIR env var honoured; never silently falls back to platform default when set \ example from the issue) - Locator inserted before Venv so Hatch claims its envs first - 15 unit tests covering layout depth (rejects 2 / 4 levels), HATCH_DATA_DIR semantics, project-local config, and platform defaults
Performance Report (Linux) ➖
Legend
|
Test Coverage Report (Linux)
Coverage increased! Great work! |
Performance Report (Windows) ✅
Legend
|
Test Coverage Report (Windows)
Coverage increased! Great work! |
Performance Report (macOS)
Legend
|
There was a problem hiding this comment.
Pull request overview
This PR adds first-class Hatch environment detection to PET by introducing a new pet-hatch locator and wiring it into the existing locator chain so Hatch-managed venvs are classified as Hatch rather than the generic Venv.
Changes:
- Add new
pet-hatchcrate implementing aHatchlocator with default-storage and workspace-configured discovery/identification. - Register
LocatorKind::HatchandPythonEnvironmentKind::Hatch, and insert Hatch into the locator chain beforeVenv. - Update refresh-state contract expectations to mark Hatch as
RefreshStatePersistence::ConfiguredOnly.
Show a summary per file
| File | Description |
|---|---|
| crates/pet/src/locators.rs | Adds the Hatch locator into the ordered locator chain before Venv. |
| crates/pet/src/jsonrpc.rs | Updates the refresh-state contract test to include LocatorKind::Hatch. |
| crates/pet/Cargo.toml | Adds pet-hatch as a dependency of the main pet crate. |
| crates/pet-hatch/src/lib.rs | Implements Hatch detection (default storage + workspace-configured) and adds unit tests. |
| crates/pet-hatch/Cargo.toml | Defines the new pet-hatch crate and its dependencies. |
| crates/pet-core/src/python_environment.rs | Adds PythonEnvironmentKind::Hatch. |
| crates/pet-core/src/lib.rs | Adds LocatorKind::Hatch. |
| Cargo.lock | Records the new pet-hatch crate and dependency graph updates. |
Copilot's findings
- Files reviewed: 7/8 changed files
- Comments generated: 2
- Cache resolved virtual dirs in configure() so try_from() does not re-parse pyproject.toml / hatch.toml on every executable identification attempt. - Expand ~ (and \C:\Users\kanadig/\) in configured dirs.env.virtual values via pet_fs::path::expand_path so values like '~/.virtualenvs' resolve against the user home. - Build the new cache outside the workspace_virtual_dirs lock to keep disk I/O out of the critical section. - Serialize env-var-mutating tests via a per-binary mutex so cargo's default multi-threaded harness cannot race.
dmitrivMS
previously approved these changes
May 8, 2026
A Hatch project can configure dirs.env.virtual = '~/.virtualenvs' (or any path that overlaps with WORKON_HOME). With Hatch placed after VirtualEnvWrapper, those envs would be claimed as VirtualEnvWrapper before Hatch ever saw them. Move Hatch ahead so it gets first claim on workspace-configured envs.
dmitrivMS
previously approved these changes
May 8, 2026
- get_default_virtual_dir(): no longer requires the path to exist on disk at construction time. The long-lived locator graph is built once at server startup; users may install Hatch (or create the first env) later in the same process. find() now re-checks existence at call time so newly-created envs are discovered without a restart. - try_from(): do the cheap path-shape classification (default storage / configured workspace dirs) BEFORE reading pyvenv.cfg, so non-Hatch venvs flowing through the locator chain do not pay an extra filesystem read. - try_from(): inspect the workspace cache under the lock and capture the match instead of cloning the entire cache on every identification attempt.
- resolve_project_virtual_dirs(): cache configured paths regardless of whether the directory exists on disk yet. A user may configure 'virtual = .hatch' and create the env later in this process lifetime; we now recognise it without requiring the client to re-send 'configure'. find_envs_in_flat_dir() already handles missing dirs by returning empty. - default_virtual_dir field doc: corrected to reflect that the path may not exist on disk; existence is rechecked at find() time. - Module docs: aligned with implementation. All workspace-configured 'dirs.env.virtual' paths use the flat layout, regardless of whether they are relative, absolute, or use ~ expansion.
Use serde 1.0.152 to match the dominant version string used across the workspace. Both 1.0.152 and 1.0.226 are semver-compatible and resolve to the same compiled crate, but matching the workspace style avoids inconsistency. Keep toml at 0.9.7 (already used by pet-uv).
Comment on lines
+241
to
+250
| fn get_default_virtual_dir(environment: &dyn Environment) -> Option<PathBuf> { | ||
| // If HATCH_DATA_DIR is set and non-empty, Hatch *only* uses that location | ||
| // — it never falls back to the platform default. Mirror that behaviour. | ||
| // Do not fall through to platform defaults, or we'd risk attributing | ||
| // platform-default envs to Hatch when the user has redirected Hatch | ||
| // elsewhere. | ||
| if let Some(custom) = environment.get_env_var("HATCH_DATA_DIR".to_string()) { | ||
| if !custom.is_empty() { | ||
| return Some(norm_case(append_virtual_subdir(PathBuf::from(custom)))); | ||
| } |
Comment on lines
+388
to
+401
| fn resolve_project_virtual_dirs(workspace: &Path) -> Vec<PathBuf> { | ||
| let mut dirs = Vec::new(); | ||
| for raw in read_configured_virtual_paths(workspace) { | ||
| // Expand ~ and ${HOME}/${USERNAME} so configured values like | ||
| // "~/.virtualenvs" resolve to the user home rather than being | ||
| // joined onto the workspace as a relative path. | ||
| let expanded = expand_path(PathBuf::from(&raw)); | ||
| let resolved = if expanded.is_absolute() { | ||
| expanded | ||
| } else { | ||
| workspace.join(expanded) | ||
| }; | ||
| dirs.push(norm_case(resolved)); | ||
| } |
roblourens
approved these changes
May 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #450.
Adds a new
pet-hatchcrate so Hatch-managed virtual environments are no longer misclassified as plainVenvby downstream consumers.Implementation
Matches Hatch's actual storage layout from
src/hatch/env/virtual.py:<data_dir>/env/virtual/<project_name>/<project_id>/<venv_name>(3 levels deep, not 2).HATCH_DATA_DIRis honoured and never silently falls back to the platform default when set.[tool.hatch.dirs.env].virtualinpyproject.tomlor[dirs.env]inhatch.toml. Handles thevirtual = ".hatch"example called out in the issue.Venvso it claims envs first.LocatorKind::Hatchregistered asRefreshStatePersistence::ConfiguredOnly(workspace-driven discovery).Tests
15 unit tests covering:
HATCH_DATA_DIRsemantics — used when set, no fallback to platform default.pyproject.tomlandhatch.toml; rejected withoutdirs.env.virtualconfig.platformdirsdefaults (Linux/macOS/Windows).Replaces #451
This PR replaces #451, which had a fundamental layout bug: it assumed envs are stored 2 levels deep under
<data_dir>/env/virtual(<project-hash>/<env-name>). Per Hatch's source, the actual layout is 3 levels deep (<project_name>/<project_id>/<venv_name>), so #451 would fail to detect any real Hatch env in the default storage location.