Pop — Dependencies#

Module info#

• Module: github.com/gobuffalo/pop/v6
• Go version: 1.25.0
• Direct dependencies: 21
• Indirect dependencies: ~36 listed in go.mod; go.sum has 203 lines (~101 unique module versions)

Dependency categories#

Core infrastructure#

• github.com/gobuffalo/logger v1.0.7 — thin logrus wrapper that satisfies pop’s internal Logger interface; used in almost every package for SQL and migration logging
• github.com/gobuffalo/envy v1.10.2 — environment variable management with .env file loading (godotenv under the hood); used for database URL resolution at startup
• github.com/fatih/color v1.19.0 — terminal colour output; used by the soda CLI to highlight migration status and errors
• golang.org/x/sync v0.20.0 — provides errgroup for concurrent association eager-loading

Networking/HTTP#

None. Pop is a pure database/ORM library; it has no HTTP surface.

Data/Storage#

• github.com/jmoiron/sqlx v1.4.0 — the foundational layer; pop wraps sqlx’s DB and Tx types to get named query binding and struct scanning, avoiding raw database/sql boilerplate
• github.com/go-sql-driver/mysql v1.9.3 — registered MySQL/MariaDB driver (blank-import pattern in dialect files)
• github.com/lib/pq v1.12.0 — legacy PostgreSQL driver; included alongside pgx for backward compatibility
• github.com/jackc/pgx/v5 v5.9.1 — modern PostgreSQL driver; used via its stdlib compatibility shim (pgx/v5/stdlib) so sqlx can drive it transparently
• github.com/mattn/go-sqlite3 v1.14.37 — SQLite3 driver; notably a CGo dependency, the only one in the graph, which forces CGo-enabled builds for any project embedding pop with SQLite support
• github.com/luna-duclos/instrumentedsql v1.1.3 — wraps database/sql drivers with tracing hooks; pop uses it to intercept all SQL calls and emit structured log lines with elapsed time
• github.com/gobuffalo/nulls v0.4.2 — nullable type wrappers (NullString, NullInt64, etc.) that round-trip through database/sql/driver.Value
• github.com/gofrs/uuid v4.4.0+incompatible — UUID type used for model IDs; implements sql.Scanner and driver.Valuer
• github.com/gobuffalo/fizz v1.14.4 — pop’s migration DSL; translates Ruby-like DSL (create_table, add_column, etc.) into dialect-specific SQL at migration time
• gopkg.in/yaml.v2 v2.4.0 — database.yml config file parsing; the older v2 API (not v3) is used here

CLI / Code generation#

• github.com/spf13/cobra v1.10.2 — CLI framework powering the soda binary; all soda subcommands (db create, db migrate, db generate) are Cobra commands
• github.com/gobuffalo/attrs v1.0.3 — attribute name/type helpers used by soda generate model to parse command-line field definitions (e.g., name:string)
• github.com/gobuffalo/flect v1.0.3 — string inflection library (pluralization, snake_case, PascalCase); used by model name derivation and table name conventions
• github.com/gobuffalo/genny/v2 v2.1.1 — Buffalo’s code generation framework; soda generate uses it to write model and migration files via a dry-run/disk generator pattern
• github.com/gobuffalo/plush/v4 v4.1.22 — template engine (HTML-safe Go templates with helpers); used by genny to render model and migration file templates
• github.com/gobuffalo/validate/v3 v3.3.3 — validation framework; pop’s Validatable interface hooks into this so models can declare field validators before Save

Testing#

• github.com/stretchr/testify v1.11.1 — assertion library (require/assert); used pervasively in test files for database interaction assertions

Stdlib reliance#

Pop is moderately stdlib-heavy for a library of its purpose. Import frequency in non-test source:

The heavy reflect usage is expected for an ORM (struct field enumeration). database/sql appears only 10 times because sqlx abstracts most of the low-level work. The project avoids stdlib log (1 use) in favour of its own logging sub-package.

Shared dependencies#

Dependencies that appear in many other projects in the 50-repo set:

• github.com/spf13/cobra — ubiquitous across CLI-bearing projects (consul, vault, helm, nomad, etc.)
• github.com/stretchr/testify — near-universal test assertion library across the set
• golang.org/x/sync — used by virtually all concurrent Go projects
• gopkg.in/yaml.v2 — common config format; several projects use v2 while others have migrated to v3
• github.com/sirupsen/logrus (indirect, via gobuffalo/logger) — appears indirectly in many projects still on logrus
• github.com/jmoiron/sqlx — less universal but shared with any database-centric project in the set
• github.com/jackc/pgx/v5 — shared with other Postgres-first projects

Vendoring#

No vendor directory. Pop relies on the module proxy (proxy.golang.org) and Go module checksums. This is standard for an actively maintained library that expects consumers to manage their own vendor directories. The absence of vendoring keeps the repository lean (no CGo sqlite3 C sources checked in as vendor).

Notable dependency decisions#

1. Dual PostgreSQL drivers (lib/pq + pgx/v5): Pop ships both the legacy lib/pq and the modern jackc/pgx/v5. The pgx driver is used via its stdlib compatibility shim so sqlx doesn’t need to know about it, but maintaining two Postgres drivers adds ~2MB to the dependency graph. The motivation is backward compatibility: projects using older pop versions on lib/pq can migrate incrementally.

2. CGo via go-sqlite3: SQLite support requires CGo (mattn/go-sqlite3), which is pop’s only CGo dependency. This is a well-known trade-off in the Go ecosystem — pure-Go SQLite alternatives (like modernc.org/sqlite) exist but pop hasn’t adopted one. Any consumer of pop that imports the SQLite dialect must enable CGo, complicating cross-compilation.

3. Deep gobuffalo ecosystem lock-in: 8 of 21 direct dependencies are gobuffalo/* packages (attrs, envy, fizz, flect, genny, logger, nulls, plush, validate). This tight coupling is intentional — pop is Buffalo’s ORM — but makes it heavyweight for standalone use outside the Buffalo framework, where consumers pay for plush, genny, attrs, etc. even if they only need the ORM core.

4. instrumentedsql for SQL-level observability: Rather than adding tracing at the application layer, pop wraps every driver with instrumentedsql before registering it. This centralises all timing/logging in one place and keeps individual dialect files clean, but it does mean tracing is always on (filtered by log level) with no zero-cost path.

5. yaml.v2 instead of yaml.v3: Pop uses the older gopkg.in/yaml.v2 for database.yml parsing while also indirectly pulling in yaml.v3 (via other gobuffalo deps). This split is a sign of incremental migration within the ecosystem rather than a deliberate choice; yaml.v3 has better type safety but was a breaking change.