2 commits

Author	SHA1	Message	Date
Wasim Yousef Said	72ab966221	Installer: suppress macOS uv developer tools dialog (#8479) ... * Desktop: stop the loopback client following redirects `loopback_http::client` is the client that posts `.desktop_secret` to /api/auth/desktop-login, and it was built without a redirect policy. reqwest follows up to 10 redirects by default, and its cross-host protection strips headers rather than bodies, so a responder answering 307 (which preserves the method and the body) would carry the secret to whatever the Location header names, after the loopback URL had already been checked. Its sibling `streaming_client` already refuses redirects for exactly this reason: "Redirects are refused so a loopback URL cannot be bounced off-host after the check." Give `client` the same policy. No behaviour change for any real backend, which never redirects these routes. * Suppress macOS uv developer tools dialog * Update workspace guard for uv wrapper * Stop the installer raising the macOS command line developer tools dialog On a Mac without the Command Line Tools, /usr/bin/git, lipo, install_name_tool and friends are libxcselect shims. Executing one resolves no developer dir and posts to com.apple.dt.CommandLineTools.installondemand, which draws the 'requires the command line developer tools' dialog naming the tool. Resolving the path does not; only execution does. Two call sites execute a shim on the consumer path: _has_working_git ran 'git --version' to decide whether git works, so on a clean Mac the probe raised the dialog it exists to detect. It now answers from the resolved path when that path is exactly /usr/bin/git and no toolchain is selected. Deliberately narrow: a Homebrew, MacPorts or Xcode.app git earlier on PATH is a real binary and is still probed by executing it, so a Mac with a working git but no CLT selected behaves exactly as before. An earlier version of this gated on 'no CLT implies no working git' and broke that case, which the existing test caught. xcode-select -p only asks which toolchain is selected and never prompts. The venv arch probe called lipo first and fell back to file -L. lipo is a shim; 2>/dev/null hides its stderr but not a GUI dialog. file is base system and always answers, so the order is swapped. Both spellings feed the same case below, against 'Mach-O 64-bit executable arm64' or 'universal binary ... [x86_64] [arm64]' rather than lipo's 'arm64' / 'x86_64 arm64', so the branch taken is unchanged. clean-machine-assert.sh already made this same swap for its own use. The cctools binaries were missing from the clean machine CI tool list, so none of this was visible: trace mode generated no wrapper and the absent list never checked them. install_name_tool, lipo, otool, objdump, vtool, strip and nm are added, which is what makes these fixes regression testable. test_macos_clt_gate.sh gains two cases pinning the contract: with a shim git and no toolchain selected the probe answers no WITHOUT executing it, proven by a stub that records execution into a marker file, and with a real git elsewhere on PATH the stub IS executed. The first assertion passed vacuously when written (wrong temp path meant the marker could never be created) and was fixed by making its pair fail first. 18 to 23 passing. * Preserve working git on Intel macOS * Keep the git shim guard on under Rosetta --------- Co-authored-by: danielhanchen <unslothai@gmail.com> Co-authored-by: danielhanchen <danielhanchen@users.noreply.github.com> Co-authored-by: danielhanchen <danielhanchen@gmail.com>	2026-08-11 12:19:30 -07:00
BardiaKoopah	9856d99bce	macOS: stop the Xcode CLT dialog during venv creation (#8380) ... * macOS: stop the Xcode CLT dialog during venv creation Before downloading the managed build it was asked for, uv walks PATH and executes each interpreter it finds to read its version. On a Mac with no Command Line Tools, /usr/bin/python3 is Apple's xcode_select tool shim (byte-identical to /usr/bin/git and /usr/bin/clang), so that probe pops the "command line developer tools" dialog naming python3, for a toolchain this install never uses. These three call sites already request an explicit managed build (cpython-X-macos-aarch64-none), so --python-preference only-managed only stops the search. It changes nothing about which interpreter is chosen. Left alone deliberately: the non-arm64 branch a few lines down takes _python_request, which passes through a user's --python override or an explicit interpreter path, and only-managed would ignore an interpreter they asked for. First install only. Once uv has a matching managed CPython cached it does not probe PATH at all, so a re-run was already quiet either way. Note the ordering this removes: _check_macos_deps at 2233 already prints "no Xcode Command Line Tools (not required)" before uv then prompts for them anyway. * Keep the offline system-Python fallback for PR #8380 only-managed also disables uv's system-interpreter fallback, so an offline Mac with no cached managed build went from a working venv to a fatal 'No interpreter found ... in managed installations'. Route the three arm64 sites through _uv_venv_arm64, which retries the request unflagged when the managed-only attempt fails, and add a regression test. * Harden the macOS venv fallback for PR #8380 Simulated the venv block across 90 platform combinations (OS x arch x --python x pre-existing venv) and confirmed the uv argv is byte-identical to main everywhere except macOS arm64, where only the flag is added. Two more configurations join offline in losing the install without a fallback: UV_PYTHON_DOWNLOADS=never and UV_NO_MANAGED_PYTHON=1. Note why the flag is spelled --python-preference (accepted since uv 0.4.30, vs 0.8.16 for --managed-python), and guard the Studio installer stream: the recovery has to emit ERROR_CLEAR or install.rs keeps reporting a failure it recovered from. * Tighten the comments added for PR #8380 Comment-only pass, verified: with comment and blank lines stripped, all three changed files hash identically to 4687bac18. --------- Co-authored-by: danielhanchen <danielhanchen@gmail.com>	2026-08-11 02:34:05 -07:00