140 lines
6.6 KiB
Markdown
140 lines
6.6 KiB
Markdown
---
|
|
title: "zig, git-subtrac and dependencies"
|
|
date: 2022-04-23T05:37:51+03:00
|
|
draft: 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"[^1] have package managers[^2], 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[^3]. 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](https://github.com/mattn/go-sqlite3),
|
|
[uber/zap](https://github.com/uber-go/zap),
|
|
[apenwarr/redo](https://github.com/apenwarr/redo) and
|
|
[django](https://djangoproject.com) 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](https://github.com/motiejus/sql-migrate).
|
|
|
|
To sum up, the "modern" languages optimize for initial development experience,
|
|
not maintenance. And as [Corbet says][linux-rust]. "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`][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`][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](https://andrewkelley.me/) 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`][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.
|
|
|
|
[git-subtrac]: https://github.com/apenwarr/git-subtrac/
|
|
[linux-rust]: https://lwn.net/SubscriberLink/889924/a733d6630e3b5115/
|