chore(deps): upgrade psycopg packages to version 3.3.0#8222
chore(deps): upgrade psycopg packages to version 3.3.0#8222sriramveeraghanta merged 3 commits intopreviewfrom
Conversation
WalkthroughUpdated Postgres-related packages and CI Python pin; removed some DRF filter backends and OpenAPI response exports; applied small refactors and formatting changes across several view, URL, task, and test files. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (7)
💤 Files with no reviewable changes (3)
✅ Files skipped from review due to trivial changes (1)
🧰 Additional context used🧠 Learnings (2)📚 Learning: 2025-10-17T10:46:13.825ZApplied to files:
📚 Learning: 2025-10-29T09:17:54.815ZApplied to files:
🧬 Code graph analysis (2)apps/api/plane/tests/contract/api/test_cycles.py (1)
apps/api/plane/app/views/search/base.py (2)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (4)
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 |
There was a problem hiding this comment.
Pull request overview
This PR upgrades the psycopg PostgreSQL adapter packages from version 3.2.9 to 3.3.0 across all three related packages (psycopg, psycopg-binary, and psycopg-c). The upgrade maintains consistency across the dependency stack and is compatible with the existing Django 4.2.26 framework. This is a maintenance update to keep database adapter dependencies current.
Key changes:
- Upgraded psycopg package from 3.2.9 to 3.3.0
- Upgraded psycopg-binary package from 3.2.9 to 3.3.0
- Upgraded psycopg-c package from 3.2.9 to 3.3.0
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/api/requirements/base.txt(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Agent
- GitHub Check: Analyze (javascript)
🔇 Additional comments (1)
apps/api/requirements/base.txt (1)
1-73: Clarify testing scope for the psycopg upgrade.The PR summary notes "lightly manually tested end-to-end." For a database driver upgrade, consider documenting whether automated tests cover:
- Database connection establishment (sync and async, if applicable)
- Query execution and result handling
- Data integrity and type conversions
- Connection pooling (if used)
- Error scenarios and recovery
This helps ensure the upgrade doesn't introduce subtle regressions in production.
| psycopg==3.3.0 | ||
| psycopg-binary==3.3.0 | ||
| psycopg-c==3.3.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check the actual requirements file content around the psycopg packages
cat -n apps/api/requirements/base.txt | head -20Repository: makeplane/plane
Length of output: 497
🏁 Script executed:
# Check if there are multiple requirements files and how psycopg is managed across them
find apps/api/requirements -type f -name "*.txt" | sortRepository: makeplane/plane
Length of output: 189
🏁 Script executed:
# Look for any setup.py, setup.cfg, or pyproject.toml that might define psycopg extras
fd -t f \( -name "setup.py" -o -name "setup.cfg" -o -name "pyproject.toml" \) apps/Repository: makeplane/plane
Length of output: 289
🏁 Script executed:
# Search for any comments or documentation about psycopg package choice
rg -B 3 -A 3 "psycopg" apps/api/requirements/ -C 2Repository: makeplane/plane
Length of output: 399
🌐 Web query:
psycopg 3 binary c extension separate pinning requirements.txt best practice
💡 Result:
Short best-practices for using Psycopg‑3 (binary vs C extension) and pinning in requirements.txt:
-
Choose the installer that matches your environment
- For most apps use the prebuilt wheels: pip install "psycopg[binary]". It bundles the C extension and libpq so you avoid build tools and system libpq. [1][2]
- If you need a system libpq (specific libpq features or unsupported platform) or want to build the extension yourself, install the C build: pip install "psycopg[c]" (requires libpq and build tools) or use the pure‑Python package when appropriate. [1]
-
Pin explicitly in requirements files (and lock transitive deps)
- In requirements.txt pin the package and the extra you rely on, e.g.:
psycopg[binary]==3.2.10 - If you build from source on CI/production, pin psycopg[c]== or pin the same psycopg version but ensure build deps (libpq, headers, compiler) are provided by your images. [1]
- In requirements.txt pin the package and the extra you rely on, e.g.:
-
Separate concerns (best practice)
- Keep runtime requirements (what ships to production) separate from dev/build requirements:
- requirements.txt (runtime): psycopg[binary]==X.Y.Z
- requirements-dev.txt or Dockerfile (build/CI): system packages (libpq-dev), compiler, and optional psycopg[c] if you build locally.
- Alternatively use a lockfile tool (pip-tools, pip‑freeze, poetry.lock) to capture exact transitive versions and platform wheels for reproducible installs.
- Keep runtime requirements (what ships to production) separate from dev/build requirements:
-
Be platform-aware
- Binary wheels are produced for a set of platforms; verify your target platform/wheel exists (macOS ARM, older macOS, Linux manylinux) — if not, use local build or system libpq. Use psycopg.pq.version() / build_version to inspect bundled libpq if needed. [1][4]
-
CI / container recommendations
- For containers, either: (a) use psycopg[binary] in your runtime image (simpler), or (b) install system libpq and build tools in build stage and pin psycopg (or psycopg[c]) if you require system libpq. Keep runtime images minimal by only installing runtime wheel. [1][5]
References
- Psycopg installation docs (binary/local/pure Python and handling dependencies). [1]
- Psycopg GitHub/README install notes. [2]
- PyPI / packaging notes about psycopg-binary availability and wheel builds. [4]
If you want, tell me your target OS/Python and whether you control the container/CI and I’ll give a concrete requirements.txt + Dockerfile example.
Correct the psycopg package pinning strategy.
The upgrade to psycopg 3.3.0 is valid and backward-compatible with Django 4.2.26. However, pinning psycopg, psycopg-binary, and psycopg-c separately is incorrect. These are mutually exclusive installation methods, not complementary packages:
psycopg[binary]: prebuilt wheel with bundled libpq (recommended for most deployments)psycopg[c]: source build requiring system libpq and build toolspsycopg: pure-Python fallback
The requirements file should pin only one option. For standard deployments, replace lines 8-10 with:
psycopg[binary]==3.3.0
If your deployment requires building from source, use psycopg[c]==3.3.0 instead and ensure libpq and build tools are available in your environment.
🤖 Prompt for AI Agents
In apps/api/requirements/base.txt around lines 8 to 10, the three separate pins
for psycopg, psycopg-binary, and psycopg-c are incorrect because they are
mutually exclusive installation options; remove the three lines and replace them
with a single pin for the appropriate install method (for most deployments use
psycopg[binary]==3.3.0; if you must build from source use psycopg[c]==3.3.0) and
ensure any deployment-specific system libs/build-tools are provisioned when
choosing the [c] option.
Description
chore(deps): upgrade psycopg packages to version 3.3.0
Type of Change
Test Scenarios
Summary by CodeRabbit
Chores
Bug Fixes
Style / Tests
✏️ Tip: You can customize this high-level summary in your review settings.