*: avoid sql -> c-dep dependency edges

[dt]

Some of cockroach's code is likely useful outside of just the cockroach binary. Most obvious is some of our general purpose util packages, but additionally anyone building tools that interact with Cockroach or its data such as api responses, on-disk data, backups, etc may want to reuse our defined protobufs and structs as well as the helpers and other functions we've defined around them. Such external tools, both from first or third parties, are common in healthy, thriving OSS ecosystems, and we ideally should, where practical, make it as easy as possible to use our reusable helpers both in and outside the cockroach repo.

However a point of friction currently is that Cockroach uses make to build, including to run just-in-time code generation and to handle building c dependencies for linking by cgo. Non-make driven builds of the majority of the codebase simply do not work. Solving the generation problem has been previously addressed by the creation of the cockroach-gen mirror of the repo, maintained with pre-generated code by CI.

However cgo remains a problem, rendering any package with transitive dependencies on cgo unusable outside the cockroach binary. This is unlikely to change given the platform-specific nature of our c builds and how dependent they are on make. However we can minimize the number of our Go packages that become impossible to consume externally by avoiding depending, including transitively, on cgo.

Current examples:
mvcc encoding in storage/engine is used in sql and elsewhere, but since storage/engine also handles interfacing with rocksdb, pulling in pure-Go mvcc logic pulls in cgo.
distsqlrun uses interfaces that are defined in engine and even creates stores that are backed by rocksdb, thus depending on in rocksdb directly.

This will likely require care in splitting some of the low-level packages, defining interfaces and splitting cgo-backed implementations out into separate packages. In the of the temp-store example, it would also require some form of dependency injection as it is actually calling directly into a cgo-backed implementation.

Additionally all of this is bound to rot if not enforced by machines, as large dependency graphs can easily hide edges from human inspection, so we'll want to make a list of packages that a lint inspects, to ensure their transitive dependency closures remain free of cgo imports.

[maddyblue]

I would also love to get the parser package to not depend on util/log or build. Just putting this on the wishlist. I may work on it at some point. This would make, for example, sqlfmt buildable without a buncha weird stuff that prevents easy building on windows and wasm.

[lopezator]

+1 I just made a project to be able to use sqlfmt outside cockroach binary. To use in dev time and CI time. The fight with CGO was huge.

https://github.com/lopezator/sqlfmt

Works out of the box simply with a "go get" and has cross-platform precompiled binaries.

[jordanlewis]

• sql -> jobs -> storage (for Liveness). Solvable by making a storagepb package within storage.
• sql -> serverpb -> status (for the Status proto). Solvable by making a statuspb package within status.
• sql -> status (for some protos, and MetricsRecorder). Solvable by statuspb for the protos, and a new exported interface for MetricsRecorder that lives in different package.
• sql -> storage (NodeLiveness, Liveness, StoreTestingKnobs, MergeQueueEnabled). Liveness solved by storagepb. NodeLiveness needs a new interface in a new package for a single method, IsLive. StoreTestingKnobs can move to a new package - it's a fully exported struct. MergeQueueEnabled can move to a new package - it's exported and just a field.

I think this is the full list. Very manageable.

[dt]

fwiw, making storage c-deps free is also pretty manageable: moving MVCCKey out of engine breaks a most of the storage -> engine edges.

[jordanlewis]

Fair enough, but I feel like sql->storage is kind of wonky too.