ceos/unsloth
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

ci: broaden Linux + narrow Windows llama.cpp runtime patterns + trim #5741 comments (#5746)

Browse source 
* ci: broaden Linux llama.cpp runtime pattern to lib*.so*

#5741 patched the explicit Linux pattern list to add
``libllama-*-impl.so*`` after ggml-org/llama.cpp#23462 (between
b9279 and b9283) split each binary's entry code into a paired
``lib<binary>-impl.so`` shared library. Same class of upstream
repackaging will hit us again whenever a new shared lib is added.

Mirror what macOS already does and replace the per-lib list with a
single ``lib*.so*`` glob. ``copy_globs`` (line 3614) unions
patterns, so the per-variant ``libggml-cuda.so*`` / ``libggml-hip.so*``
entries were never filtering anything; the spec lives in
``runtime_payload_health_groups`` (line 5209) which keeps the
explicit minimum-required list per variant.

Dry-run against b9296-bin-ubuntu-x64.tar.gz: 40 files copied (all
ggml, llama, mtmd, impl variants + the two binaries we ship), 22
skipped (other CLIs, rpc-server, LICENSE). Functionally equal to
the post-#5741 set.

* cleanup: trim #5741 comments on the pydantic split

Comments added in #5741 explained the original bug in full each
time. They are mostly redundant with the commit message and the PR.
Trim them to one short paragraph per site.

No behavior change.

* ci: narrow Windows runtime pattern to llama-server.exe + llama-quantize.exe

Studio only invokes llama-server and llama-quantize. Mac and Linux
already filter to those two binaries; Windows was the odd one out
with ``*.exe`` copying every CLI upstream ships (llama-cli,
llama-bench, llama-mtmd-cli, ...).

Dry-run on b9296 (win cpu-x64, cpu-arm64, cuda-13.1, hip-radeon):
20 unused EXEs skipped per variant, all DLLs (incl. the new
llama-*-impl.dll family) still copied via ``*.dll``.

``existing_install_matches_choice`` already checks llama-server.exe
exists explicitly (line 5297), so the health gate is unchanged.
This commit is contained in:
Daniel Han 2026-05-23 21:48:12 -07:00 • committed by GitHub
commit dfb3eedf77
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
6 changed files with 38 additions and 85 deletions
Download patch file Download diff file Expand all files Collapse all files

21
studio/install_python_stack.py
View file

@ -979,22 +979,11 @@ def install_python_stack() -> int:
package_name,
"unsloth-zoo",
)
# Pydantic ships its core as a separate compiled wheel
# (pydantic-core), and pydantic's ``_ensure_pydantic_core_version``
# checks the installed core matches the exact version pinned in
# its own metadata. With ``--no-deps`` plus an unpinned
# ``pydantic`` / ``pydantic-core`` pair in no-torch-runtime.txt,
# pip resolved each to the newest available version and the two
# drifted (pydantic 2.13.4 pins pydantic-core==2.46.4 today, but
# pydantic-core 2.47.0 was the latest). On a fresh Windows venv
# the next ``import pydantic`` raised ``SystemError: ...
# incompatible with the current pydantic version``.
#
# Resolve them WITH deps in a focused pip call so pip picks a
# compatible pair. pydantic's own deps are
# ``annotated-types``, ``pydantic-core``, ``typing-extensions``,
# ``typing-inspection`` -- none of which transitively pull
# torch, so this is safe for the no-torch path.
# Resolve pydantic WITH deps so pip pins pydantic-core to the
# exact version pydantic's metadata declares. Under --no-deps
# alone pip picks the latest of each and trips pydantic's
# _ensure_pydantic_core_version check. Transitive deps are
# torch-free.
pip_install(
"Installing pydantic (with deps for compatible core)",
"--no-cache-dir",