fix(prepare): handle freshness check for auto-created venvs

[jdx]

Summary

• Fixes issue where mise prepare incorrectly skips dependency installation when a venv is auto-created
• When venv is auto-created during config loading, its timestamp is newer than the lock file, causing the freshness check to incorrectly conclude dependencies are "fresh"
• Adds in-memory tracking of directories created during the current session
• When check_freshness() runs, outputs created this session are considered stale

Fixes: #7762

Test plan

• Create a test project with [env._.python.venv] and [prepare.uv] configured
• Run mise prepare on first entry - should run uv sync
• Run mise prepare again - should report "fresh" (skip sync)
• Touch uv.lock and run mise prepare - should run uv sync again

🤖 Generated with Claude Code

---

Note

Ensures prepare runs when outputs like .venv are auto-created during env resolution, preventing false "fresh" detections.

• Add in-memory tracking of session-created outputs via mark_output_stale, is_output_stale, and clear_output_stale in src/prepare/mod.rs
• Update check_freshness() to consider is_output_stale(output) before mtime comparison
• After venv creation, call crate::prepare::mark_output_stale(venv) in src/config/env_directive/venv.rs
• Execute providers in parallel and return outputs; upon all success, clear flags with clear_output_stale in src/prepare/engine.rs
• Extend e2e tests to validate directory output freshness behavior (.venv vs requirements.txt)

^{Written by Cursor Bugbot for commit 2195b47. This will update automatically on new commits. Configure here.}

[Copilot]

Pull request overview

This PR fixes an issue where mise prepare incorrectly skips dependency installation when a Python virtual environment is auto-created during config loading. The problem occurs because the newly created venv has a timestamp newer than the lock file, causing the freshness check to incorrectly conclude that dependencies are already installed.

Changes:

• Adds in-memory tracking of directories created during the current session using a static LazyLock<Mutex<HashSet<PathBuf>>>
• Modifies freshness check logic to treat outputs created during the current session as stale
• Marks auto-created venvs as stale and clears this status after successful prepare execution

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/prepare/mod.rs	Adds global state tracking and helper functions for managing stale output paths
src/prepare/engine.rs	Updates prepare execution flow to check stale status and clear it after successful runs
src/config/env_directive/venv.rs	Marks newly created venvs as stale for prepare freshness checks

Comments suppressed due to low confidence (1)

src/prepare/mod.rs:1

• Silent failure on lock poisoning could mask issues. Consider logging a warning or error when the mutex lock fails, similar to the concern in mark_output_stale.

use std::collections::{BTreeMap, HashSet};

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Silent failure on lock poisoning could mask issues. Consider logging a warning or error when the mutex lock fails, as this would indicate a serious problem with the stale tracking mechanism.

Suggested change

	if let Ok(mut set) = STALE_OUTPUTS.lock() {
	set.insert(path);
	}
	}
	/// Check if a directory was created this session
	pub fn is_output_stale(path: &PathBuf) -> bool {
	STALE_OUTPUTS
	.lock()
	.map(|set| set.contains(path))
	.unwrap_or(false)
	}
	/// Clear stale status for a path (after prepare runs successfully)
	pub fn clear_output_stale(path: &PathBuf) {
	if let Ok(mut set) = STALE_OUTPUTS.lock() {
	set.remove(path);
	match STALE_OUTPUTS.lock() {
	Ok(mut set) => {
	set.insert(path);
	}
	Err(err) => {
	warn!("prepare: failed to mark output as stale due to poisoned mutex: {err}");
	}
	}
	}
	/// Check if a directory was created this session
	pub fn is_output_stale(path: &PathBuf) -> bool {
	match STALE_OUTPUTS.lock() {
	Ok(set) => set.contains(path),
	Err(err) => {
	warn!("prepare: failed to check stale output due to poisoned mutex: {err}");
	false
	}
	}
	}
	/// Clear stale status for a path (after prepare runs successfully)
	pub fn clear_output_stale(path: &PathBuf) {
	match STALE_OUTPUTS.lock() {
	Ok(mut set) => {
	set.remove(path);
	}
	Err(err) => {
	warn!("prepare: failed to clear stale output due to poisoned mutex: {err}");
	}

[Copilot]

Clearing stale status happens after prepare succeeds, but if multiple providers share the same output path and one fails while another succeeds, the output might be incorrectly marked as non-stale. Consider whether clearing should only happen after all prepare steps complete successfully.

[github-actions]

Hyperfine Performance

mise x -- echo

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.1.5 x -- echo	19.7 ± 0.5	19.1	24.8	1.00
mise x -- echo	19.8 ± 0.3	19.1	23.2	1.00 ± 0.03

mise env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.1.5 env	19.1 ± 0.4	18.6	25.2	1.00
mise env	19.5 ± 0.6	18.6	26.2	1.02 ± 0.04

mise hook-env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.1.5 hook-env	19.3 ± 0.2	18.7	20.2	1.00
mise hook-env	19.5 ± 0.3	18.9	20.6	1.01 ± 0.02

mise ls

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.1.5 ls	17.3 ± 0.4	16.6	18.6	1.00
mise ls	17.3 ± 0.3	16.7	21.7	1.00 ± 0.03

xtasks/test/perf

Command	mise-2026.1.5	mise	Variance
install (cached)	109ms	108ms	+0%
ls (cached)	66ms	71ms	-7%
bin-paths (cached)	70ms	70ms	+0%
task-ls (cached)	282ms	283ms	+0%