proxy: ask GitHub for the asset name CLIProxyAPI actually publishes - #430
Open
sergeivad wants to merge 1 commit into
Open
proxy: ask GitHub for the asset name CLIProxyAPI actually publishes#430sergeivad wants to merge 1 commit into
sergeivad wants to merge 1 commit into
Conversation
Two ways picking the release asset went wrong.
Wrong name. CLIProxyAPI publishes its 64-bit ARM builds as `aarch64`, not
`arm64`. The downloader asked for `arm64`, so it matched nothing on
exactly the two platforms Nerve is most likely to run on — an Apple
Silicon Mac and an ARM VPS. It surfaced during `nerve init` as "No
CLIProxyAPI asset found for darwin_arm64", which reads as a missing build
rather than a misnamed one, and pushed the operator toward buying a
separate API key instead of fixing a string.
Wrong build. Each platform ships twice, a full build and a stripped
`_no-plugin` one, so the suffix is a substring of two asset names. The
match had no tiebreak and took the first hit, making the winner whatever
order GitHub returned — the no-plugin build, in each of the last five
releases. Matching the anchored tail `_{suffix}.tar.gz` picks the full
build regardless of ordering. The loop moves out of the async,
network-bound `_download_binary` into `_select_asset_url` so it can be
tested against an asset list rather than a live release.
Also drops `"AMD64": "windows_amd64"` from `_ARCH_MAP`. The map is only
read inside the `if system == "linux"` branch, and `AMD64` is a spelling
`platform.machine()` uses only on Windows, where the function raises
before reaching the map. Even reachable it would not have helped: the
extractor opens `.tar.gz` and Windows assets are `.zip`. The comment
above the map now says what the map is — Linux only — rather than
implying Windows support that was never wired up.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two separate problems in picking the CLIProxyAPI release asset.
Wrong name
CLIProxyAPI publishes its 64-bit ARM builds as
aarch64, notarm64. The downloader asked forarm64, so it matched nothing on exactly the two platforms Nerve is most likely to run on: an Apple Silicon Mac and an ARM VPS.It surfaced during
nerve initas:which reads as a missing upstream build rather than a misnamed lookup, and pushes the operator toward buying a separate API key instead of fixing a string.
Wrong build
Each platform ships twice — a full build and a stripped
_no-pluginone — so the suffix is a substring of two asset names. The match had no tiebreak and took the first hit, making the winner whatever order the GitHub API returned. That was the no-plugin build in each of the last five releases.Matching the anchored tail
_{suffix}.tar.gzpicks the full build regardless of ordering.Also
_download_binaryinto_select_asset_url, so it can be tested against an asset list instead of a live release."AMD64": "windows_amd64"from_ARCH_MAP. The map is only read inside theif system == "linux"branch, andAMD64is a spellingplatform.machine()uses only on Windows, where the function raises before reaching the map. Even if it were reachable it would not have helped — the extractor opens.tar.gzand Windows assets are.zip. The comment above the map now says the map is Linux-only rather than implying Windows support that was never wired up.Tests
tests/test_proxy_asset_suffix.pycovers the naming and the full-vs-no-plugin tiebreak against a synthetic asset list. Full suite green on top of currentmain.