Protobuf dependency conflict: votify crashes at import with the librespot extra (upstream #103 / #105)

[JavaGT]

Protobuf dependency conflict: votify crashes at import with the librespot extra (upstream glomatico#103 / glomatico#105)

Evidence (all verified locally, 2026-09-13)

Three layers combine:

1. Undeclared direct dependency. votify's generated protobuf code (votify/api/proto/*_pb2.py, header "Protobuf Python Version: 6.33.4") imports google.protobuf.runtime_version (protobuf >= 5.27), but pyproject.toml never declares protobuf — it arrives only transitively via pywidevine>=1.9.0. requirements.txt already declares protobuf>=6.33.5 while pyproject does not (split-brain). Environments where protobuf resolves older crash at startup with ImportError: cannot import name 'runtime_version' (the traceback in upstream ImportError: cannot import name 'runtime_version' from 'google.protobuf' glomatico/votify#103).
2. Unbounded librespot extra. pyproject.toml:32-33 allows librespot>=0.0.1. PyPI metadata (fetched 2026-09-13): librespot 0.0.2 pins protobuf==4.21.0 and 0.0.3–0.0.10 pin protobuf==3.20.1 — all irreconcilable with pywidevine's >=6.33.0,<7 (upstream Dependency conflict: protobuf incompatibility between librespot and pywidevine makes Votify unusable glomatico/votify#105).
3. Even the resolvable combo breaks at runtime. librespot 0.0.1 + protobuf 6.33.x (what the maintainer's own uv.lock ships) crashes when the librespot session is used: librespot 0.0.1's gencode predates protoc 3.19 and dies with TypeError: Descriptors cannot be created directly under the default upb backend (verified on Python 3.14). Amplifier: SpotifyApi.__init__ defaults to session_type=SessionType.LIBRESPOT (votify/api/api.py:47), so the extra is on the default README path.

Proposed fix (staged as a fork PR, linked below)

• Declare protobuf>=6.33.5 directly in [project].dependencies (no <7 cap — protobuf's official cross-version runtime guarantee supports gencode since 3.20.0 through runtime 8.x).
• Cap the extra: librespot>=0.0.1,<0.0.2 (the only release whose metadata can resolve with protobuf 6.x).
• In votify/__init__.py, os.environ.setdefault("PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION", "python") guarded by find_spec("librespot"), so the default librespot session works out of the box; users without the extra keep the faster upb backend.
• Regenerate uv.lock.

Attribution

This issue was produced with AI assistance under the direction of @JavaGT: exploration, evidence verification and implementation by GLM agents (ZCode); plan and diff audited by OpenAI GPT-5.6 ("Luna") and xAI Grok 4.6 via opencode.

[JavaGT]

Update: the owner already opened the upstream PR for this finding themselves — glomatico#110 (opened 2026-09-13 from fix/protobuf-conflict, "Fixes glomatico#105, fixes glomatico#103"). No fork PR is staged for this bundle to avoid duplicating the owner's upstream work. Fork branch fix/protobuf-conflict (e342610) remains the staging copy.

[JavaGT]

Live reproduction 2026-09-15 (votify 1.9.9, macOS 15 arm64, Python 3.13, fresh uv venv + pip install -e '.[librespot]'): confirmed the import-time crash — librespot ships pre-3.19-era generated pb2 code and dies inside protobuf 6.x with TypeError: Descriptors cannot be created directly.

One step further: the import failure is not the last blocker for the librespot session. With PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python set (pure-Python protobuf, slow but functional), librespot imports, builds a session, and logs in — then Spotify's token endpoint rejects it:

librespot.mercury.MercuryClient.MercuryException: status: 403
  librespot/core.py get_token -> MercuryRequests.request_token(...)

librespot-python is unmaintained upstream (2022), so even with the protobuf pin fixed, the librespot session type looks locked out at Spotify's side. Today's reachable song paths are web (AAC, requires .wvd CDM) and desktop (requires Windows Spotify.dll 1.2.88.483). That likely changes the shape of an upstream glomatico#105 fix: a dependency constraint alone won't restore the librespot path. Worth a second-account check before writing the fix.

[JavaGT]

Root-cause follow-up, 2026-09-15 (source reading + cross-client survey; no code changed). Three findings that change the shape of the fix:

1. The 403 is universal, not account-specific — a second-account check is unnecessary.
votify resolves librespot 0.0.1 (uv.lock:340-341). Its token call is Session.get_token (core.py:1771) → MercuryRequests.request_token (mercury.py:302-311): a Mercury GET (Mercury = Spotify's legacy binary RPC channel over the logged-in "access point" connection) to

hm://keymaster/token/authenticated?scope=playlist-read&client_id=65b708073fc0480ea92a077233ca87bd&device_id=…

triggered by the first metadata fetch (get_metadata_4_track → tokens().get("playlist-read"), core.py:59). Auth is the AP session itself plus librespot's hardcoded public client_id. Spotify began rejecting this endpoint for librespot-family clients around 2025-08-12, hitting unrelated clients on unrelated platforms the same day: librespot-org/librespot#1532 ("just started happening within the past 24 hours", Rust 0.6.0), zotify-dev/zotify#295 (same day), later glomatico#100 (Apr 2026, Windows, same playlist-read 403) and stiefenm/spoton#91 (Jun 2026). votify's web/desktop sessions work on the same sp_dc, so the account is in good standing — the keymaster endpoint is the problem.

2. librespot-python is maintained again and has the fix upstream.
kokarare1212/librespot-python resumed active maintenance Aug 2025 (commits through Aug 2026). Release 0.0.10 (PyPI 2025-11-13) removed the keymaster call: TokenProvider.get_token now mints tokens via Login5 — an HTTPS POST to https://login5.spotify.com/v3/login (core.py:2310-2337) using the reusable credential from APWelcome — which is mechanically compatible with votify's token login (votify/api/librespot.py:15-19). Its 403-era issues #306/#310 were closed as fixed by that rework. (Rust librespot fixed the same break in v0.7.0, Aug 2025.)

3. Revival path for votify: point the extra at librespot-python ≥0.0.10 or a fork of it. Two blockers remain: 0.0.10 pins protobuf==3.20.1 (conflicts with pywidevine's protobuf>=6.33,<7) and still ships pre-protoc-3.19 pb2 gencode (140 _internal_create_key occurrences in Keyexchange_pb2.py alone) — so a fork needs a relaxed protobuf constraint plus regenerated stubs (or keep the PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python shim). Unverified end-to-end: Vorbis also needs the AP-packet audio-key exchange (AudioKeyManager.get_audio_key, audio/init.py:258 in 0.0.10), which no public post-2025 report confirms.

Attribution: AI-assisted investigation (GLM via ZCode) under @JavaGT direction.

[JavaGT]

Prior-art survey supplement, 2026-09-15 (read-only ecosystem sweep; deltas beyond the root-cause comment above):

1. The exact upstream fix for the 403: kokarare1212/librespot-python PR #311 "Use Login5 Authentication Instead of Keymaster" (merged 2025-08-17), refined by #312 (2025-09-19), shipped in PyPI librespot 0.0.10 (2025-11-13); verified in the v0.0.10 tag. So the token layer is fixed upstream itself, not only in forks.
2. The protobuf layer is fixed nowhere. Upstream issue #130 (regenerate protos) has been open since 2022-05-28; PR #330 (protobuf 6.33 bump) was closed unmerged 2026-06-09. Every fork (librespot-spotizerr 0.3.0, librespot-spotizerr-phoenix 0.0.13) still pins protobuf==3.20.1. Caveat for fork-based pins: the spotizerr fork was DMCA-taken-down 2025-08-20 at kokarare1212's own request (github/dmca 2025/08/2025-08-20-librespot-python.md) and successors may share that exposure — upstream is the legally clean line.
3. The audio-key caveat is documented, not just unverified: audio-key fetch fails for newer accounts across the whole family — librespot-python #325/#315, Audio key error librespot-org/librespot#1649 (last activity 2026-01-13). So even on 0.0.10 the librespot session has a hard ceiling for newer accounts.
4. PyPI lag: upstream main is ~10 months ahead of 0.0.10 (#329 OAuth token manager, #347 credential-format compat are main-only).

Decision this surfaces for upstream glomatico#110 (currently caps the extra at librespot>=0.0.1,<0.0.2 — co-installs with protobuf 6.x but stays 403-locked): keep that shape as a crash-only fix, or repoint to 0.0.10 with a neutralized protobuf pin, accepting the audio-key ceiling? A protobuf-regeneration PR against kokarare1212/librespot-python (#130, open since 2022, maintainer demonstrably merging again) would unblock every Python consumer at once — that is owner-reviewed upstream contact, so flagging rather than filing.

[JavaGT]

Decision-2 staging: the 0.0.10 repoint is now staged as PR #16 (fix/librespot-0.0.10-repoint), pointing the librespot extra at JavaGT/librespot-python@protobuf-6-compat (v0.0.10 + regenerated protobuf stubs + protobuf>=4.25.1,<7).

Dependency layer verified (installs, imports under protobuf 6.33.6, pywidevine co-exists). New evidence from live testing, extending the Login5 picture in the earlier comments: with 0.0.10 the session gets past the old keymaster 403 and reaches Login5, but Login5 answers INVALID_CREDENTIALS (error 1) to the reusable credential issued to a token-authenticated AP session — so end-to-end downloads still fail, now one step later, matching devgianlu/go-librespot#364. Probed with secrets redacted; details in the PR body.