Skip to content

webui: resolve install packages by target directory, not a family allowlist - #408

Closed
CryptVenture wants to merge 1 commit into
0xShug0:mainfrom
CryptVenture:pr/webui-package-resolution
Closed

webui: resolve install packages by target directory, not a family allowlist#408
CryptVenture wants to merge 1 commit into
0xShug0:mainfrom
CryptVenture:pr/webui-package-resolution

Conversation

@CryptVenture

Copy link
Copy Markdown
Contributor

Split out of #373 as requested. This PR is the package resolver in catalog.ts and the button rendering it drives; the catalog entries, the request wiring, the transcript display and the UI text fixes are separate PRs.

The problem

catalog.ts grouped install choices with a hardcoded six-family allowlist. Families on the list exposed every package; every other family was narrowed to at most one q8 and one fp16 button. Measured by executing catalog.ts against the real specs, 130 of the published packages were reachable from the WebUI.

The change

  • Group by target_directory, not by family name. Packages that are precision variants of one model share a directory; packages that are different models do not. The allowlist had to be hand-edited for every new family and silently hid the rest.
  • Extend the precision-suffix list to q2_kq6_k, q4_0, q5_0, f32. It covered only q8/f16/bf16/safetensors/orig, so an entry whose download_id ended in an uncovered suffix collapsed to that single package and hid its siblings — which is why PersonaPlex offered only Q4_K while its own spec marks Q8_0 default.
  • Honour ui.recommended_package. Every spec has one, all resolve to a real package, and nothing read the field.
  • Match relatedness on target_directory, not an id prefix. The prefix test pulled the IndexTTS2.5 packages into the IndexTTS2 entry, whose fp16 slot was then decided by spec-file array order.
  • Keep an entry with no installable package, flagged, instead of letting the model vanish from the UI.

Why the labels are in this PR

The button text is chosen while the choice is built, in the same function. Shipping the two separately would leave one PR with a label nothing produces, or buttons whose text does not fit their border. Each entry's buttons are labelled by build (Q8_0, Q4_K ConvRot); where several models share a directory and collide on precision the label keeps what their display names do not share (XL Turbo BF16), falling back to the full name if even that is ambiguous. The full name stays on the title and aria-label.

Validation

npx svelte-check --tsconfig ./tsconfig.json
# 153 FILES 0 ERRORS 0 WARNINGS

Reachability measured by loading catalog.ts through Vite's SSR loader and diffing the resolved package-id sets:

main this branch
catalog entries 85 85
install buttons rendered 150 166
distinct packages reachable 130 143
packages lost 0

Label check over every entry: 0 entries with two buttons reading alike, longest label 13 characters (XL Turbo BF16).

Scope

catalog.ts, types.ts, the package-button block of +page.svelte, and the button rules in app.css. The generated bundle (webui/native/dist/index.html) is deliberately excluded: it is not byte-reproducible, so regenerating it in each PR of this split would make the PRs conflict with each other. Happy to send one bundle-regeneration PR once the series lands.

…owlist

A third of the shipped GGUF packages could not be installed from the native
WebUI. catalog.ts grouped install choices with a hardcoded six-family
allowlist: families on the list exposed every package, everything else was
narrowed to at most one q8 and one fp16 button. Measured by executing
catalog.ts against the real specs, 130 of the published packages were
reachable; after this change 143 are, and none are lost.

  - Group install choices by target_directory. Packages that are precision
    variants of one model share a directory; packages that are different models
    do not. The allowlist had to be edited by hand for every new family.
  - Extend the precision-suffix list to q2_k..q6_k, q4_0, q5_0 and f32. It
    covered only q8/f16/bf16/safetensors/orig, so an entry whose download_id
    ended in an uncovered suffix collapsed to that single package and hid its
    siblings, which is why PersonaPlex offered only Q4_K while its own spec
    marks Q8_0 default.
  - Honour ui.recommended_package. Every spec has one, all of them resolve to a
    real package, and nothing read the field.
  - Match relatedness on target_directory instead of an id prefix. The prefix
    test pulled the IndexTTS2.5 packages into the IndexTTS2 entry, whose fp16
    slot was then decided by spec-file array order.
  - Keep an entry that has no installable package, flagged, instead of letting
    the model disappear from the UI entirely.

Labels come from the same resolution step, so they are here rather than in a
follow-up: the button text is chosen while the choice is built, and shipping
one without the other would leave either a label nothing produces or buttons
whose text does not fit. Each entry's buttons are labelled by build ("Q8_0",
"Q4_K ConvRot"); where several models share a directory and collide on
precision, the label keeps what their display names do not share ("XL Turbo
BF16"), and falls back to the full name if even that is ambiguous. No entry has
two buttons that read alike, and the longest label is 13 characters. The full
name stays on the title and the aria-label, and both button lines clamp inside
the border.

+page.svelte now renders the slots catalog.ts hands it (studioPackageSlots is
installPackageSlots) rather than re-deriving the set from family names.

Validation:
  npx svelte-check --tsconfig ./tsconfig.json     # 153 files, 0 errors
  reachable packages 130 -> 143, none lost, measured by loading catalog.ts
  through Vite's SSR loader and diffing the id sets
@CryptVenture
CryptVenture force-pushed the pr/webui-package-resolution branch from 23345a3 to c84dcb5 Compare September 3, 2026 00:50
@CryptVenture

Copy link
Copy Markdown
Contributor Author

Closing for now to stay inside the 3-concurrent-PR policy (see the discussion on #422). Nothing is wrong with the change and CI is green on it; I will reopen it as review slots free.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant