rqlite records its development dependencies in Go modules
rqlite's 5.0 development branch adopts Go modules. Explicit requirements make the selected Raft and SQLite driver dependencies visible to contributors and build tooling.
A database source tree depends on particular implementations of its storage and consensus machinery. An import path alone does not state which revision supplies either one. On 31 July, Philip O'Toole announced Go module support in rqlite's 5.0 branch, crediting Elliot Courant's contribution. This is development-branch dependency management, rather than an announcement that a 5.0 binary has shipped.
The distinction matters for anyone evaluating the change through the latest stable release. The announcement describes work toward the next major branch. Its value is making build inputs explicit in that source tree. It does not by itself establish an upgrade procedure or a new cluster compatibility guarantee.
I value rqlite's choice to combine SQLite and Raft in a relatively compact system. Those dependencies carry substantial responsibility even when the surrounding application is small. Recording their versions where contributors can inspect them is useful engineering information about the database being built.
The requirements name concrete implementations
The module file added by the contribution declares github.com/rqlite/rqlite as the module path and a Go language version of 1.12. Its requirements include HashiCorp Raft v1.1.0 and go-sqlite3 v1.10.0. The file also records the CLI dependencies and a cryptography dependency. These names describe actual build inputs, rather than a generic statement that the application uses consensus and SQL.
Several dependencies use pseudo-versions containing a timestamp and commit identifier. The Go 1.12.7 command documentation explains how these identify untagged revisions using version syntax that Go can order. A dependency does not need a release tag before its selected revision can be recorded in the module requirements.
One requirement is marked indirect. That annotation distinguishes dependencies needed through other modules from packages imported directly by the main module. It does not mean the dependency is irrelevant to the build. The documentation explains that the complete build list follows requirements through the dependency graph, resolving competing versions according to the module selection rules.
The build list extends beyond one file
The main module's requirements are the beginning of dependency selection. Modules referenced there can declare their own requirements. The Go documentation describes recursively assembling those requirements and retaining the highest requested semantic version when more than one version of a module appears. Reading the top-level file is therefore useful without being a complete substitute for inspecting the selected build list.
A contributor using the corresponding module-aware toolchain can ask for that list directly.
go list -m all
The command reports the main module and dependency modules selected for the build. This is more informative than treating every top-level requirement as an unconditional exact lock independent of the rest of the graph. A requirement participates in module selection, and the selected set is what ultimately supplies packages.
The documentation also distinguishes go.mod from go.sum. The latter records expected cryptographic checksums for module content. A future download must match an existing checksum. Version selection and content verification answer different questions, so the two files have separate purposes even though both belong with the source.
Module mode changes source lookup
Go's module-aware mode no longer uses GOPATH to define import resolution. GOPATH still has roles in downloaded module storage and installed commands. For the Go versions relevant to this change, the documentation describes automatic module activation outside GOPATH/src when a go.mod exists in the current directory or a parent.
That qualification is important for an existing development setup. Merely adding go.mod does not mean every old invocation in every directory instantly uses the same lookup behavior. The working directory and toolchain mode still matter. A contributor needs to distinguish a module-aware build from a legacy GOPATH build before comparing their selected dependencies.
Vendoring remains a separate choice too. The Go 1.12 documentation says ordinary module-aware builds ignore vendor directories. A build explicitly requesting -mod=vendor instead uses the main module's top-level vendor directory. The presence of copied dependency files cannot by itself establish which source a particular invocation selects.
Dependency changes become reviewable
The command documentation describes go mod tidy as examining the module's packages across build configurations to add missing requirements and remove unnecessary ones. It also provides -mod=readonly to make ordinary build commands fail when they would need to update go.mod. These are concrete tools for maintaining a dependency declaration instead of relying on whatever revisions happen to be available locally.
I see the immediate benefit as a more explicit description of the database build. A reviewer can inspect changes to the named Raft implementation or SQLite driver alongside the application change that requires them. That does not prove a new dependency is compatible, but it makes the intended input available for review.
The July announcement establishes that this machinery is now present in the 5.0 development branch. The module requirements identify dependencies at that point in the work, and module-aware tooling can explain the full selected graph. Contributors can discuss a build in terms of recorded versions and content checksums while the branch continues developing.