* Studio: detect an interrupted dependency install instead of launching a backend that cannot import An installer killed part-way leaves a venv with a working CLI but without studio.txt's dependencies. Nothing recorded that, so three separate places all reported it healthy: - the desktop preflight probed only `unsloth -h` (typer + rich) and a hardcoded desktop-capabilities dict, neither of which touches studio.backend, so it returned ManagedReady and spawned a backend that died on `import structlog`; - setup.sh's fast path compared the installed unsloth version against PyPI, which matches on a half-built venv because unsloth is installed early, so `unsloth studio update` printed "up to date" and repaired nothing; - start_managed_repair calls that update and then re-checks with the same blind probes, so Repair reported success without fixing anything. install_python_stack.py now clears a completion manifest before the dependency pass and writes it only after the final step. `unsloth studio verify-install` and desktop-capabilities' new studio_install_ok field read it, the preflight turns a false answer into ManagedStale so auto-repair runs, and setup.sh / setup.ps1 gain an escape hatch next to the existing anyio one. Separately, the wheel ships studio/ and studio.backend* but declared none of their dependencies, so `unsloth train`, `export`, `chat`, `inference` and `studio` all ended in a rich traceback after a plain pip install. structlog is the only hard module-level import that chain reaches once starlette's annotation-only import moves under TYPE_CHECKING, so it becomes a core dependency and the rest of the server stack becomes a [studio] extra mirroring studio.txt. The CLI import sites now report missing dependencies as a sentence with two remedies. Fixes #4701, #5260, #7147 * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Match the trimmed comments merged on the pip branch * Put the install manifest in the preflight fingerprint for PR #7492 The capability cache keyed the venv on pyvenv.cfg, uv.lock, requirements.txt, the interpreter and site-packages/unsloth_cli/commands/studio.py, none of which a repair touches when it only reinstalls studio.txt. So an entry cached while the install was healthy stayed valid after the manifest was dropped, and the probe returned Ready on exactly the half-built venv this is meant to catch. * Address the review findings on PR #7492 Fail the install when the completion manifest cannot be written, instead of exiting 0 without the record every later check requires, which is a repair loop by construction. Compare the version of the package the manifest names, so `studio update --package X` does not read as a permanent version change. Read the manifest from the venv that owns it when the CLI runs outside the managed venv, and drop the dependency verdict in that case: the walk ran against the wrong interpreter and says nothing about that venv. Name the import that actually failed. `unsloth train` reaches torch through the same guard, and the studio extra does not carry it, so recommending that extra alone left the command failing in the same place. * Declare click, which typer stopped providing, for PR #7492 unsloth_cli/commands/start.py imports click at module scope and unsloth_cli/__init__.py imports that module, so every unsloth command needs it. typer carried click through 0.19 and dropped it in 0.27, and the declared floor is typer>=0.12.0, so a fresh resolve gets no click. On the published wheel it still arrives because huggingface_hub requires click<9,>=8.4.2, which is luck rather than a declaration. A wheel built from this branch's dependency list has neither, and every command dies at import. Verified: before, `unsloth --help` on a fresh venv raised ModuleNotFoundError for click; after, it exits 0. The drift test now covers it. * Keep a running backend from the previous app version manageable The manageability bump gated two unrelated things through one constant. For the managed CLI probe 2 is right: a CLI reporting 1 cannot answer studio_install_ok. For a RUNNING backend it is wrong, because a process already started cannot change what it reports, so bumping studio/backend/main.py in lockstep does not help one the previous app version spawned. That backend is proven ours by root id and ownership token, but lifecycle_control_block_reason returned Unmanageable, and that branch never calls adopt_verified_backend. has_owned_backend() stays false, so Repair falls into block_external_conflict, which finds the same process and refuses: the app could no longer stop a backend it owns the token for. The same regression in backend.rs turned a terminal-launched same-root server from AttachedReady into ExternalConflict. Split the constant: DESKTOP_BACKEND_MANAGEABILITY_VERSION = 1 for the two live-backend probes, DESKTOP_MANAGEABILITY_VERSION = 2 for the CLI probe. Every real gate (protocol, auth, ownership, desktop-login, MIN_DESKTOP_BACKEND_VERSION) is untouched, so an old backend still reaches OwnedStale, adopt, stop, repair. Also stop the installer when the stale manifest cannot be removed. Windows raises on a read-only or locked file, and the pass would then run behind a marker that still names this version and these digests, so a run killed part-way would verify as complete. * Answer for the managed venv, not the one the CLI happens to run in The guard matched ModuleNotFoundError.name, an import name, against missing_requirements(), which returns distribution names. So a missing PyJWT printed 'pip install jwt', and jwt, docx and fitz are each a real but unrelated PyPI project (fitz is a neuroimaging workflow tool), so following the advice installed the wrong package and left the backend just as broken. Map the import to its distribution before deciding, and never offer the import itself. install_state() verified the caller's own prefix. The wheel ships studio/, so a CLI installed outside the managed venv always finds its own copy of the helper first, and a healthy managed install reported studio_install_incomplete with a missing list copied from the wrong venv. Selecting the root is not enough: _installed_version() reads the running interpreter and req_root defaults to the caller's studio.txt, so both checks still answered for the wrong venv. Hand verify_install() that venv's own metadata, enumerated through Distribution.discover(context = ...path), which does not fall back to sys.path. The candidate order is untouched, so shadowed-tree detection is unchanged. setup.ps1 replaces pip, torch and triton before install_python_stack.py runs, so the manifest it drops is not dropped before the first mutation. A run killed in between kept a marker that still verifies while torch was half-replaced; drop it at the top of the dependency pass instead. setup.sh is unaffected, the stack is the first thing its pass runs, and a test now pins both. pip uninstall rewrites nothing that was fingerprinted, and cache_matches re-reads the cached studio_install_ok rather than re-checking, so a venv that lost a studio.txt package kept being served the healthy verdict. Fold a sorted hash of the installed dist-info names into the marker hash. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * A missing manifest helper is a torn install, not an old one studio/install_manifest.py ships in the same wheel as _studio_deps.py, so nothing legitimately has one without the other: a CLI predating both never reaches this code, and the desktop already calls such a CLI stale on desktop_manageability_version. Returning ok=true there reported a healthy install for a tree the package update had half replaced, and the preflight then launched a backend whose own run.py could be just as absent. Report it incomplete so repair runs. * Tighten comments across the install-detection changes * Validate Studio dependency readiness --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Lee Jackson <130007945+Imagineer99@users.noreply.github.com> Co-authored-by: Wasim Yousef Said <wasimysdev@gmail.com>
161 lines
6.3 KiB
YAML
161 lines
6.3 KiB
YAML
# SPDX-License-Identifier: AGPL-3.0-only
|
|
# Copyright 2026-present the Unsloth AI Inc. team. All rights reserved.
|
|
|
|
# Builds the PyPI wheel from the PR branch, then verifies the built wheel
|
|
# actually contains what we expect to ship and does NOT contain the broken
|
|
# Unsloth bundle that 2026.5.1 published. This is the single workflow that
|
|
# would have blocked the 2026.5.1 release before twine upload.
|
|
#
|
|
# Verified locally end-to-end against this branch:
|
|
# - python -m build produces unsloth-<version>-py3-none-any.whl in 13s
|
|
# - wheel content sanity passes:
|
|
# lockfile shipped, frontend dist shipped,
|
|
# no node_modules in wheel, no bun.lock in wheel,
|
|
# main bundle has unstable_Provider hits=1 (assistant-ui internals only).
|
|
# - Unsloth backend imports cleanly from the installed wheel with the
|
|
# lightweight dep set below.
|
|
|
|
name: Wheel CI
|
|
|
|
on:
|
|
pull_request:
|
|
paths:
|
|
- 'pyproject.toml'
|
|
- 'studio/**'
|
|
- 'unsloth/**'
|
|
- 'unsloth_cli/**'
|
|
- '.github/workflows/wheel-smoke.yml'
|
|
push:
|
|
branches: [main, pip]
|
|
|
|
concurrency:
|
|
group: ${{ github.workflow }}-${{ github.ref }}
|
|
cancel-in-progress: true
|
|
|
|
permissions:
|
|
contents: read
|
|
|
|
jobs:
|
|
wheel:
|
|
name: Wheel build + content sanity + import smoke
|
|
runs-on: ubuntu-latest
|
|
timeout-minutes: 15
|
|
steps:
|
|
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
|
with:
|
|
persist-credentials: false
|
|
|
|
- uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
|
|
with:
|
|
node-version: '22'
|
|
|
|
- uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
|
|
with:
|
|
python-version: '3.12'
|
|
|
|
- name: Lockfile supply-chain audit (pre-install scan)
|
|
run: python3 scripts/lockfile_supply_chain_audit.py
|
|
|
|
- name: Build frontend
|
|
# Lifecycle scripts (esbuild native-binary postinstall, etc.) are
|
|
# required for `vite build`. The pre-install lockfile structural
|
|
# audit (lockfile_supply_chain_audit.py) is the practical defence
|
|
# against the npm postinstall-dropper class -- it fires BEFORE any
|
|
# tarball runs, on the injection pattern itself rather than an
|
|
# advisory-DB lookup.
|
|
run: |
|
|
cd studio/frontend
|
|
npm ci --no-fund --no-audit
|
|
npm run build
|
|
|
|
- name: Build wheel + sdist
|
|
run: |
|
|
python -m pip install --upgrade pip build
|
|
rm -rf dist build ./*.egg-info
|
|
python -m build
|
|
|
|
- name: Wheel content sanity
|
|
run: |
|
|
python - <<'PY'
|
|
import zipfile, glob, sys
|
|
w = glob.glob("dist/unsloth-*.whl")
|
|
if not w:
|
|
print("FAIL: no wheel produced"); sys.exit(2)
|
|
w = w[0]
|
|
print(f"wheel: {w}")
|
|
with zipfile.ZipFile(w) as z:
|
|
n = z.namelist()
|
|
checks = {
|
|
"lockfile shipped": any(s.endswith("studio/frontend/package-lock.json") for s in n),
|
|
"frontend dist shipped": any(s.endswith("studio/frontend/dist/index.html") for s in n),
|
|
"no node_modules": not any("studio/frontend/node_modules/" in s for s in n),
|
|
"no bun.lock": not any(s.endswith("studio/frontend/bun.lock") for s in n),
|
|
}
|
|
js = [s for s in n
|
|
if "studio/frontend/dist/assets/" in s
|
|
and s.endswith(".js")
|
|
and "/index-" in s]
|
|
if not js:
|
|
print("FAIL: no main bundle index-*.js in wheel"); sys.exit(2)
|
|
data = z.read(js[0]).decode("utf-8", "replace")
|
|
hits = data.count("unstable_Provider:")
|
|
print(f"main bundle: {js[0]}")
|
|
print(f"unstable_Provider hits: {hits} (>=4 indicates 2026.5.1 regression)")
|
|
checks["bundle has no Unsloth unstable_Provider call site"] = (hits < 4)
|
|
|
|
print()
|
|
for k, v in checks.items():
|
|
print(f" [{'PASS' if v else 'FAIL'}] {k}")
|
|
sys.exit(0 if all(checks.values()) else 1)
|
|
PY
|
|
|
|
- name: Unsloth backend import smoke
|
|
# Imports `studio.backend.main:app` from the freshly-installed wheel in
|
|
# a clean venv. This catches the class of bug that 2026.5.1 shipped with:
|
|
# frontend dist missing, package-lock.json missing, or the wheel's Python
|
|
# source tree broken in a way that surfaces only at app construction time.
|
|
run: |
|
|
python -m venv /tmp/v
|
|
/tmp/v/bin/pip install --upgrade pip
|
|
/tmp/v/bin/pip install -r studio/backend/requirements/studio.txt
|
|
/tmp/v/bin/pip install \
|
|
python-multipart aiofiles sqlalchemy cryptography \
|
|
pyyaml jinja2 mammoth unpdf requests \
|
|
'numpy<3'
|
|
/tmp/v/bin/pip install --no-deps dist/unsloth-*.whl
|
|
# Run from /tmp so Python imports the installed package, not the source tree.
|
|
cd /tmp
|
|
/tmp/v/bin/python -c "from studio.backend.main import app; print('Unsloth backend OK:', app.title)"
|
|
|
|
- name: CLI without the Studio stack guides instead of tracebacking
|
|
# The smoke above installs studio.txt first, so it cannot catch a wheel
|
|
# that ships studio/ without declaring what it imports (#4701, #5260,
|
|
# #7147). Drop only structlog to reuse that venv without a re-download.
|
|
run: |
|
|
set -eu
|
|
/tmp/v/bin/pip uninstall -y structlog >/dev/null
|
|
cd /tmp
|
|
status=0
|
|
for args in "export ./nope ./out" "list-checkpoints"; do
|
|
echo "--- unsloth $args"
|
|
out=$(/tmp/v/bin/unsloth $args 2>&1 || true)
|
|
printf '%s\n' "$out"
|
|
case "$out" in
|
|
*Traceback*)
|
|
echo "FAIL: raw traceback instead of guidance"; status=1 ;;
|
|
esac
|
|
case "$out" in
|
|
*'unsloth studio update'*) ;;
|
|
*) echo "FAIL: no remediation in the message"; status=1 ;;
|
|
esac
|
|
done
|
|
/tmp/v/bin/pip install -q structlog >/dev/null
|
|
exit "$status"
|
|
|
|
- name: Upload wheel on failure
|
|
if: failure()
|
|
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
|
|
with:
|
|
name: unsloth-wheel
|
|
path: dist/
|
|
retention-days: 7
|