github-featured / unslothai--unsloth

发布

0 发布 84 Git 标签

RSS 订阅源
  • v0.1.701-beta 72ab966221
    比较

    Installer: suppress macOS uv developer tools dialog (#8479)

    frostbyte_neo 发布于 2026-08-11 19:19:30 +00:00

    • 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

    下载附件