ac447bc76f fix: detect psycopg3 and add required apt packages (#350)
* feat: add psycopg (psycopg3) to postgres dependency detection

Added psycopg to the list of Python dependencies that trigger installation
of PostgreSQL libraries (libpq-dev for build, libpq5 for runtime).

While psycopg[binary] includes a bundled libpq, the base psycopg package
and psycopg[c] both require system libpq. Since we cannot determine which
variant is being used from dependency files, we conservatively install
libpq when any psycopg dependency is detected.

Also added integration test example for psycopg3 to verify the dependency
detection works correctly.

* chore: add tmp/ to .gitignore

* test: enhance psycopg3 example to test actual database connectivity

Updated the python-psycopg3 example to:
- Connect to a real PostgreSQL database
- Execute test queries to verify connectivity
- Use docker-compose.yml to provide postgres service for integration tests
- Assert on multiple output strings to verify full connection lifecycle

This provides a comprehensive test that psycopg can successfully use
the system libpq libraries to connect to and query PostgreSQL.

* test: upgrade psycopg3 example to Python 3.14 and assert major version

Updated the python-psycopg3 example to:
- Use Python 3.14 (latest stable release)
- Specify psycopg>=3.2,<4.0 to ensure psycopg3 is used
- Add runtime check that verifies psycopg major version is 3
- Update test assertion to match new output message

This ensures the test explicitly validates we're using psycopg3 (not
psycopg2) and tests compatibility with the latest Python version.

* refactor: convert python-psycopg3 example to use uv and latest Python

- Changed .python-version from 3.14 to "latest"
- Converted from pip to uv package manager
- Created pyproject.toml with psycopg>=3.2,<4.0 dependency
- Generated uv.lock for reproducible builds
- Removed requirements.txt
- Reverted .gitignore changes (removed tmp/)

* test: update snapshot

---------

Co-authored-by: Hanzo Dev <[email protected]>
2025-11-20 15:38:37 -07:00
2025-10-22 12:07:18 -06:00
2025-03-24 09:49:31 -07:00
2025-02-10 13:26:33 -07:00
2025-02-06 21:07:15 -05:00

Railpack

CI Run Tests

Railpack is a tool for building images from source code with minimal configuration. It is the successor to Nixpacks and incorporates many of the learnings from running Nixpacks in production at Railway for several years.

Getting Started

# Install mise & railpack
curl -sSL https://mise.run | sh
mise install ubi:railwayapp/railpack@latest

# start BuildKit container & let railpack know about it
docker run --rm --privileged -d --name buildkit moby/buildkit
export BUILDKIT_HOST='docker-container://buildkit'

# create a Next.js app
npm create next-app@latest my-app
cd my-app

# build and run the app!
railpack build .
docker run -p 3000:3000 -it my-app

Railpack automatically detects the project type (next, in this case, but many languages & frameworks are supported!) and generates an optimized container image.

Note: The above steps are for running Railpack locally to experiment and test. If you deploy on Railway, Railpack runs automatically when you push changes to your repository.

Documentation

Full documentation for both operators (platforms, like Railway) and users (developers using Railpack to build their applications) is available at railpack.com.

Contributing

Railpack is open source and open to contributions. See the CONTRIBUTING.md file for more information.

S
Description
Zero-config BuildKit gateway frontend for the Hanzo build fabric
Readme MIT
24 MiB
Languages
Go 90.8%
Shell 6.5%
Python 1.4%
Dockerfile 0.7%
TypeScript 0.6%