refactor(build_environment): use self.run() in _createenv()

[smoparth]

_createenv() called external_commands.run() directly while every other method uses self.run(), duplicating ctx-access logic for network_isolation. The --python CLI flag passed to uv venv takes precedence over UV_PYTHON set by get_venv_environ(), so the swap is safe.

Having a single entry point for command execution simplifies auditing and future cross-cutting changes like environment filtering or network policy enforcement.

Closes: #1276

Pull Request Description

What

Why

• PR follows CONTRIBUTING.md guidelines

[coderabbitai]

Warning

Review limit reached

@smoparth, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 44 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 878f595f-2350-4033-ba05-8f46f9be3734

📥 Commits

Reviewing files that changed from the base of the PR and between c1a2f23 and b9ade11.

📒 Files selected for processing (1)

• src/fromager/build_environment.py

📝 Walkthrough

Walkthrough

BuildEnvironment._createenv now executes the uv venv command through self.run(cmd) instead of calling external_commands.run directly. This centralizes environment preparation and preserves context-based network isolation defaults.

Estimated code review effort: 1 (Trivial) | ~3 minutes

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main refactor in _createenv().
Description check	✅ Passed	The description matches the code change and explains the motivation clearly.
Linked Issues check	✅ Passed	The refactor satisfies #1276 by routing _createenv() through self.run() and removing duplicated command setup.
Out of Scope Changes check	✅ Passed	No unrelated or extra changes are indicated beyond the requested BuildEnvironment refactor.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[tiran]

The _createenv function does not use BuildEnvironment.run for a reason. The BuildEnvironment.run assumes that the virtual env exists.

[smoparth]

The _createenv function does not use BuildEnvironment.run for a reason. The BuildEnvironment.run assumes that the virtual env exists.

Even I thought same. I understand by the time _createenv() runs VIRTUAL_ENV, PATH, and UV_PYTHON all point to the not-yet-created directory, but I verified that uv venv ignores the venv-related env vars set by get_venv_environ():

UV_PYTHON is overridden by the explicit --python sys.executable CLI flag
VIRTUAL_ENV and PATH are not consulted by uv venv -- it creates the venv at the positional path argument

I tested this locally by running UV_PYTHON=/nonexistent/bin/python3 uv venv --python $(python3 -c "import sys; print(sys.executable)") --no-project /tmp/test-venv and it succeeds.

That said, if the design intent is for self.run() to only be used once the venv exists, that makes sense -- I mainly wanted to understand the reasoning behind keeping it separate. Happy to close the PR if you'd prefer it stays as-is.