jakstys.lt/content/log/git-subtrac.md

title	date	draft
zig, git-subtrac and dependencies	2022-04-23T05:37:51+03:00	true

TLDR: modern programming languages make it very easy to add many dependencies. That is nice for development, but a nightmare for maintenance. Unfortunately, zig is following suit. I wish we could accept that adding dependencies does not have to be trivial. If we accept that, thanks to ubiquity of git, we may have almost solved the dependency problem.

Adding dependencies

All of the programming languages I've used professionally whose name does not start with "c"¹ have package managers², which make "dependency management" easy. These package managers will, as part of the project's build process, download and build the dependencies, making adding and using third-party dependencies easy.

Because C/C++ still does not have a universal package manager, not adding external dependencies to C/C++ is the path of least resistance. Instead, it is common to rely on libraries already installed in the system. Because of this cultural difference, there is a plethora of dependency managers that will discover, but not install dependencies: autotools, cmake, pkg-config and others. As a result, C/C++ projects I've been involved usually had 0-5 non-system dependencies, whereas non-C/C++ projects -- tens, hundreds or thousands³. Having many system dependencies is painful for user experience, so (the good) C/C++ projects also avoid having too many of them.

Not doing things that are easy to do requires discipline: brushing teeth, limiting candy intake, not adding dependencies all over the place. If it is easy to add dependencies and there is no discipline not doing so, the project will gain a lot of dependency "weight" with time.

{{<img src="_cheese/2022/brick-house.jpg" alt="House made out of Duplo pieces" caption="Just like this brick house, "modern" package managers are optimized for building, not maintenance. Photo mine, house by my sons." hint="photo" >}}

In Go and Python small number of dependencies is often a sign of care and quality. mattn/go-sqlite3, uber/zap, apenwarr/redo and django are good examples. Making it easy to depend on external code is is convenient during development, but frees developers from their basic right (or obligation?) to audit understand them. And adds real long-term maintenance costs.

The costs of just having dependencies are huge. I haven't done a survey and have only my experience to base this on (read: "many anecdotes of me failing to build stuff I wrote a decade ago"). But it is bad enough that I have a dependency checklist and am prepared to do grunt work to avoid or strip it. Here is my checklist:

• Obvious: does it work at all?
• How easy is it to build, run and run it's tests?
• Is it well written? API surface, documentation, tests, error handling, error signaling, logging, metrics (if applicable), etc.
• It's system dependencies.
• It's transitive dependencies.

If a dependency is well written, but has more transitive dependencies than I need and there is no good alternative, I will fork it and remove unnecessary code and dependencies. My recent example is sql-migrate.

To sum up, the "modern" languages optimize for initial development experience, not maintenance. And as Corbet says. "We can't understand why Kids These Days just don't want to live that way". Kids want to build, John, not maintain. A 4-letter Danish corporation made a fortune by selling toys that do not need to be maintained: they are designed to be disassembled and built anew. It is very hard to change the guts of an existing structure without rebuilding it.

If I may combine Corbet's views with mine: if we understand and audit our dependencies (and transitive ones), we will have less dependencies and a more maintainable system. Win-win.

Which brings us to...

Transitive dependencies and git-subtrac

git-subtrac does not deal with transitive dependencies. At least not directly. Or I am not aware of it. Ok, I haven't tried.

If we audit and thus understand our dependencies, we will be able to add transitive ones to our project even without support of git-subtrac. So perhaps git-subtrac shouldn't care?

I use git-subtrac for some of my projects, and am not very enthusiastic about Zig getting it's own package manager (can we all use git-subtrac and be done with it?). A few weeks ago in a park in Milan my conversation with Andrew Kelley was something like:

• me: "git-subtrac yadda yadda yadda submodules but better yadda yadda yadda".
• Andrew: "if I clone a repository that uses it with no extra parameters, will it work as expected?"
• me: "no, you have to pass --recursive, so git will checkout submodules... even if they are already fetched."
• Andrew: "then it's a piece-of-shit-approach."

Uh, I agree. People have not grown muscle memory to clone repositories with --recursive flag and never will, so it's impossible to adopt git-subtrac beyond well-controlled silos. Which is why we will have a yet-another-programming-language-specific-package-manager, this time for zig. Or at least my argument for using git-subtrac stops right there.

Why git-subtrac?

git-subtrac is like "classic" git submodules, but all refs of the dependencies stay in the same repository. Wait, stop here. Repeat after me: it is git submodules, but all refs stay in the same repository. I also call it "good vendoring". Since all the deps are in our repo, no external force can make our dependency unavailable.

It is, howerver, harder to add a dependency with submodules than with, say, go get <dependency>. Let's talk about adding dependencies.

Conclusion

Can git checkout local submodules when they are in the same repository, so our conversation of reconsidering (or not having) a zig package manager doesn't stop after 5 seconds?

---

1. Alphabetically: Erlang, Go, Java, Javascript, PHP, Perl, Python. ↩︎

2. Usually written in the same language. Zoo of package managers (sometimes a couple of popular ones for the same programming language) is a can of worms in an on itself worth another blog post. ↩︎

3. go.sum of a project I am currently involved clocks around 6k lines. This is quite a lot for Go, but still peanuts to Node.js. ↩︎