Installer: run the uv install script with a process-scoped execution policy - #132
Conversation
…policy On a fresh Windows machine the PowerShell execution policy defaults to "Restricted". The uv install script checks the effective policy and refuses to run under it, so the installer aborted halfway through with an instruction to run "Set-ExecutionPolicy" manually and start over. Pass "-ExecutionPolicy Bypass" to the one PowerShell process that runs the uv install script. The flag is process-scoped: the machine's policy is not changed, and no manual step is needed anymore. For the remaining edge case - a policy enforced system-wide via managed device policies, where the flag is ignored and Set-ExecutionPolicy would not help either - the "uv could not be found or installed" error now explains the situation and points to a manual uv install (winget) as the way forward.
|
Warning Review limit reached
Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
1 participant
Problem
On a fresh Windows machine the PowerShell execution policy defaults to
Restricted. The uv install script checks the effective policy and refuses to run under it, so the installer aborted halfway through (after the venv cleanup, before any dependency work) and told the user to runSet-ExecutionPolicymanually in a PowerShell first and start over.Fix
Instead of a pre-flight check that instructs the user, the installer now removes the obstacle itself: the one PowerShell process that runs the uv install script is started with
-ExecutionPolicy Bypass. The flag is process-scoped — the machine-wide policy is not changed, and no manual step is needed anymore. All other PowerShell invocations in the scripts run inline-Commandcode, which the execution policy does not apply to, so they need no change.For the remaining edge case — a policy enforced system-wide via managed device policies, where the process-scoped flag is ignored and
Set-ExecutionPolicywould not help the user either — the existing "uv could not be found or installed" error now explains what is going on and points to a manual uv install (winget install astral-sh.uv) as the way forward.Applied to both
install/CPU/windows_cpu.batandinstall/CUDA/windows_cuda_gpu.bat(identical block).Testing
Extracted both changed blocks into a standalone script:
Get-ExecutionPolicyinside the spawned process reportsBypass(so the uv install script's policy check passes regardless of the machine default), and the extended error message renders correctly including the escaped parentheses inside theifblock.