fix(studio): revert llama.cpp default tag to latest#4797
Conversation
The latest ggml-org/llama.cpp release (b8637) now includes Gemma 4 support. Revert the temporary "b8637" pin from #4796 to "latest" so the prebuilt resolver always picks the newest release automatically without needing manual tag bumps.
Document in all three files why "latest" is preferred over "master" and when "master" should be used as a temporary override.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b6ffd94918
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| _DEFAULT_LLAMA_PR_FORCE="" | ||
| _DEFAULT_LLAMA_SOURCE="https://github.com/ggml-org/llama.cpp" | ||
| _DEFAULT_LLAMA_TAG="b8637" | ||
| _DEFAULT_LLAMA_TAG="latest" |
There was a problem hiding this comment.
Keep default llama tag pinned when resolver is unavailable
Switching the default tag to latest makes resolver outages/rate-limits silently fall back to building the repo default branch instead of a release tag: in setup.sh the fallback sets _RESOLVED_LLAMA_TAG="$_REQUESTED_LLAMA_TAG" when resolution fails (lines 606-607), and the clone path skips --branch when the ref is latest (lines 819-821). With this change, that behavior now affects default installs, so users can unexpectedly compile bleeding-edge master/main (the exact path this comment warns against), which can break reproducibility and fail against Studio expectations.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Code Review
This pull request updates the default llama tag from a specific version to 'latest' across the Python, PowerShell, and Shell setup scripts. The reviewer expressed concerns that using 'latest' as a default value may lead to unpredictable behavior if the upstream repository changes, suggesting that a more stable configuration or constant should be used instead.
|
|
||
|
|
||
| DEFAULT_LLAMA_TAG = os.environ.get("UNSLOTH_LLAMA_TAG", "b8637") | ||
| # Prefer "latest" over "master" -- "master" bypasses the prebuilt resolver |
There was a problem hiding this comment.
| # -------------------------------------------------------------------------- | ||
| # Prefer "latest" over "master" -- "master" bypasses the prebuilt resolver | ||
| # (no matching GitHub release), forces a source build, and causes HTTP 422 | ||
| # errors. Only use "master" temporarily when the latest release is missing |
| # Prefer "latest" over "master" -- "master" bypasses | ||
| # the prebuilt resolver (no matching GitHub release), | ||
| # forces a source build, and causes HTTP 422 errors. | ||
| # Only use "master" temporarily when the latest release |
Summary
b8637"b8637"to"latest"so the prebuilt resolver always picks the newest ggml-org/llama.cpp release automaticallyChanges
setup.sh:_DEFAULT_LLAMA_TAG="b8637"->"latest"setup.ps1:$DefaultLlamaTag = "b8637"->"latest"install_llama_prebuilt.py:DEFAULT_LLAMA_TAGfallback"b8637"->"latest"