nightly: install deps into a venv (fix PEP 668 install failure)

[oflatt-claude]

Problem

The nightly run failed to install after #935 was ported to render its report with eval-live:

pip install -q -r scripts/requirements.txt
error: externally-managed-environment
× This environment is externally managed

The make nightly target ran pip install against the system interpreter, which Python 3.12 on the Debian-based nightly server rejects under PEP 668.

Fix

Install the dependency into a local virtualenv (nightly/.venv) and run nightly_bench.py with that venv's python. The script does import eval_live in-process, so it must run under the interpreter the dependency was installed into.

nightly:
	python3 -m venv nightly/.venv
	nightly/.venv/bin/pip install -q -r scripts/requirements.txt
	nightly/.venv/bin/python scripts/nightly_bench.py

nightly/.venv/ is gitignored.

Verification

On Python 3.12 (same as the nightly server), python3 -m venv + pip install -r scripts/requirements.txt into the venv succeeds and import eval_live resolves from the venv. (The server needs the python3-venv package, which provides ensurepip — standard on these machines.)

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.54%. Comparing base (f99482a) to head (9f329d4).
⚠️ Report is 1 commits behind head on nightly.

Additional details and impacted files

@@             Coverage Diff             @@
##           nightly     #939      +/-   ##
===========================================
- Coverage    86.65%   86.54%   -0.12%     
===========================================
  Files           90       89       -1     
  Lines        27057    26804     -253     
===========================================
- Hits         23446    23197     -249     
+ Misses        3611     3607       -4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[codspeed-hq]

Merging this PR will degrade performance by 7.48%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 27 untouched benchmarks
⏩ 233 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	rust_rule_tableaction_hot_path[facts50000_funcs200]	24.7 ms	31.8 ms	-22.42%
⚡	Simulation	rust_rule_insert_loop[ops1000_funcs200]	641.8 µs	581.7 µs	+10.33%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing oflatt-claude:nightly-fix-venv (9f329d4) with nightly (f99482a)}

Footnotes

1. 233 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[oflatt-claude]

Pushed a second fix. The venv change above got past the pip install, but the next run then failed at the build:

cargo build --release --bin egglog --manifest-path .../Cargo.toml
error: feature `edition2024` is required ... not stabilized in this version of Cargo (1.75.0)

Cause: the crate is edition = "2024" and rust-toolchain.toml pins 1.91.0, but the nightly host's PATH puts a system cargo (1.75.0, from apt) ahead of the rustup shim. Toolchain-file overrides are a rustup feature — the system cargo ignores rust-toolchain.toml entirely, so it tries to build with 1.75.0.

Fix (21cf77c3): prepend ~/.cargo/bin to PATH at the start of nightly_bench.py so the rustup shim wins. The shim reads rust-toolchain.toml and auto-installs/uses 1.91.0; hyperfine lives there too. This mirrors what eggcc's nightly does (it sets up ~/.cargo/bin on PATH before any cargo/rustup call).

Verified locally on a box with the same setup (system PATH lacks ~/.cargo/bin): with the prepend, cargo --version in-repo resolves to 1.91.0 via the shim.