Update version bump scripts to use official CPython releases 3.15+ on iOS - #402
Open
freakboy3742 wants to merge 7 commits into
Open
freakboy3742 wants to merge 7 commits into
freakboy3742 wants to merge 7 commits into
Conversation
…fetch The try/except block in the per-tag loop only wrapped the first two operations (_resolve_release_slug and the release lookup). A failure anywhere in the second half of the loop -- the release["name"] access, the release_file API call, or the files[0]["sha256_sum"] access -- was unprotected and would raise out of update(), aborting the entire script instead of just skipping the one problematic tag. Widen the try block to cover the whole per-tag body. The two existing if-based warnings (unexpected release name, wrong file count) keep their distinct messages via continue-inside-try (which skips the except), while any other unexpected exception (network errors, KeyError, IndexError, json.JSONDecodeError, etc.) from the fetch calls is now caught by the trailing except Exception and reported with the same generic warning-and-continue behavior as before.
Catching bare Exception triggered ruff's blind-except lint rule. Narrow to the concrete exception types the per-tag fetch/parse sequence can actually raise: urllib.error.URLError (network failures), ValueError (includes json.JSONDecodeError, and the explicit resolve_release_slug raise), KeyError (missing dict keys in a malformed API response), and IndexError (an empty objects list). Verified via the same happy-path and fault-injection scripts used for the original fix, plus additional KeyError/IndexError fault-injection cases.
The previous approach (_resolve_release_slug) issued a HEAD request per
tag to python.org's human-facing /downloads/latest/python{tag}/ URL and
relied on its redirect target to find the release slug, working around
the public release API's lack of a 'starts with' filter on name/slug.
This depended on undocumented website routing behavior rather than a
documented API contract, and cost 3 requests per tag (HEAD + release +
release_file).
Replace it with two bulk requests total, regardless of tag count:
- GET .../downloads/release/?version=3&is_published=true&limit=0 for
every published Python 3.x release (limit=0 is Tastypie's convention
for 'return everything', confirmed to return all 398 objects in one
response).
- GET .../downloads/release_file/?os__slug=<slug>&limit=0 for every
release-file row for the platform's OS.
Each tag's latest matching release is then picked out client-side by
filtering on the 'Python {tag}.' name prefix and taking the max by
release_date, and its release file is looked up by resource_uri in a
dict built from the second bulk response. This only uses documented
query-param filters (version, is_published, os__slug) rather than an
exact-match slug filter paired with a redirect trick.
Also widen error handling to cover the entire per-tag body (release
filtering, file lookup, and both dict-key extractions), not just the
final digest access -- a malformed release object missing 'name' or
'release_date' previously crashed the whole run instead of warning and
skipping just that tag, the same class of bug fixed in ff522a2 for the
release-file half of the old per-tag loop.
Fix a message bug found while re-verifying: the 'no release file found'
warning quoted release['name'] (which already starts with 'Python '),
producing a doubled 'for Python Python 3.11.16' in the message.
Verified via the same manual scripts as before (live happy path,
multi-tag with some tags lacking an iOS file, bulk-fetch network
failure, malformed release_file response, missing sha256_sum, and a
new malformed-release-object case), plus the full update() dispatch
smoke test and a real briefcase-iOS-Xcode-template dry run -- all
producing identical, correct output to the pre-redesign implementation.
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
1 participant
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.
As of beeware/briefcase#3071, Briefcase is able to use the official CPython releases for iOS. This means hash calculations need to be based on the official CPython releases, not the Python-Apple-support binaries.
The script has been used to generate beeware/briefcase-iOS-Xcode-template#88.
PR Checklist:
Assisted-by: Claude Sonnet 5