fix(deps): pin psycopg[c] back to 3.3.4 - #10399
Conversation
The macOS x64 packaging job fails while installing requirements.txt:
Preparing metadata (pyproject.toml): finished with status 'error'
error: subprocess-exited-with-error
exit code: -10
Exit code -10 is SIGBUS. The only output before the crash is
setuptools' own `[tool.setuptools.ext-modules] in pyproject.toml is
still experimental` warning, so it dies while setuptools reads the
project config, well before pg_config is ever invoked.
psycopg-c ships no wheels, so every platform compiles it from the
sdist. The only build-tooling change between 3.3.4 and 3.3.5 is the
strictly pinned build requirement:
3.3.0 - 3.3.4 setuptools == 80.3.1
3.3.5 setuptools == 83.0.0
Because that pin is an equality, PIP_CONSTRAINT cannot override the
version inside the isolated build environment - the only ways to keep
3.3.5 are --no-build-isolation with a pre-seeded setuptools (which
would fork the macOS build procedure from Linux's) or an upstream
fix. Linux builds 3.3.5 fine, so this looks specific to the
relocatable-python framework the macOS bundle is built against.
Pin to 3.3.4 to unblock the build. The encoding.py rewrite that
shipped alongside the 3.3.5 bump stays untouched: it reads the
derived py_codecs/pg_codecs dicts, which are plain dicts in both
versions.
One test expectation was 3.3.5-specific. psycopg 3.3.5 added an
ISO88591 alias to its encoding table, so inverting py_codecs resolves
iso8859-1 to ISO88591; on 3.3.4 only LATIN1 exists, so
get_encoding('LATIN1') returns ['LATIN1', 'iso8859-1'] instead of
['ISO88591', 'iso8859-1']. Both are valid PostgreSQL names for the
same encoding, so the scenario now accepts either and the test passes
on 3.3.4 and 3.3.5 alike.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. WalkthroughThe psycopg dependency pin changed from 3.3.5 to 3.3.4. Encoding tests now support alternate PostgreSQL aliases and validate the encoding result once. ChangesPsycopg encoding compatibility
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This change pins psycopg to 3.3.4 for Python 3.10+ and accepts the compatible PostgreSQL encoding aliases while retaining codec validation. The supplied regression results show no remaining merge-blocking risk. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 1 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Problem
The macOS x64 packaging job fails installing
requirements.txt:Exit code
-10is SIGBUS. The only output before the crash is setuptools' own experimental-config warning, so it dies while setuptools reads the project config — well beforepg_configis invoked.Cause
psycopg-cpublishes no wheels, so every platform compiles it from the sdist. The only build-tooling change between 3.3.4 and 3.3.5 is the strictly pinned build requirement:setuptools == 80.3.1setuptools == 83.0.0Because the pin is an equality,
PIP_CONSTRAINTcannot override the version inside the isolated build environment. Keeping 3.3.5 would mean either--no-build-isolationwith a pre-seeded setuptools — forking the macOS build procedure from Linux's, with a silent drift risk wheneverrequirements.txtchanges — or an upstream fix. Linux builds 3.3.5 without trouble, so this looks specific to therelocatable-pythonframework the macOS bundle is built against.Change
Pin
psycopg[c]to 3.3.4 forpython_version >= '3.10'. The Python 3.9 pin (3.2.13) is untouched.The
encoding.pyrewrite that shipped alongside the 3.3.5 bump in #10370 needs no change: it reads the derivedpy_codecs/pg_codecsdicts, which are plain dicts in both versions.One test expectation was 3.3.5-specific. psycopg 3.3.5 added an
ISO88591alias to its encoding table, so invertingpy_codecsresolvesiso8859-1toISO88591; on 3.3.4 onlyLATIN1exists, soget_encoding('LATIN1')returns['LATIN1', 'iso8859-1']instead of['ISO88591', 'iso8859-1']. Both are valid PostgreSQL names for the same encoding, so the scenario now accepts either.Testing
python regression/runtests.py --pkg utils.driver.psycopg3— 7/7 pass with psycopg 3.3.4.pycodestyleclean on the modified test.Not verified: that 3.3.4 actually builds on the failing macOS x64 host. That change is reasoned from the sdist diff above; it needs confirmation from a Jenkins run.
Follow-up
Worth reporting the SIGBUS upstream (setuptools 83.0.0 inside a relocated
Python.framework) so the pin can be lifted. A quick reproducer on the x64 build host:Summary by CodeRabbit