wip git-subtrac

content/log/git-subtrac.md

@@ -1,58 +1,73 @@
 ---
-title: "git-subtrac met andrewrk"
+title: "git-subtrac and Zig"
 date: 2022-04-23T05:37:51+03:00
 draft: true
 ---
 
-TLDR: I wish `git clone` with default parameters would clone the submodules if
-they are in the same repository.
+TLDR: I wish plain `git clone <repository>` would check out submodules if they
+are in the same repository.
 
-git submodules meet andrewrk
-----------------------------
-
-I use [`git-subtrac`][git-subtrac] for some of my projects, and was not very
+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: "yadda yadda git submodules vendoring dependencies yadda yadda".
+- me: "git-subtrac yadda yadda yadda submodules but better yadda yadda yadda".
 - Andrew: "if I clone a repository that uses git-subtrac 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 available locally."
+  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 add `git clone --recursive
-<repo>` and never will, so it's impossible to adopt git-subtrac beyond
-well-controlled silos. Which is why we will have a
+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.
 
-About git-subtrac
------------------
+Why git-subtrac?
+----------------
 
-[`git-subtrac`][git-subtrac] manages dependencies of some of my projects. It is
-like git submodules, but all refs of the dependencies stay in the same
-repository. Wait, stop here. Repeat after me: _it is like git submodules, but
-all refs stay in the same repository_. I call it "good vendoring". Since all
-the deps are in our repo, no external force can make our dependency
-unavailable.
+[`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 than with, say, `go get
-<dependency>`. Let's talk about auditing dependencies.
+It is, howerver, harder to *add* a dependency with submodules than with, say,
+`go get <dependency>`. Let's talk about adding dependencies.
 
-Auditing dependencies
----------------------
+Adding dependencies
+-------------------
 
-In "modern" programming languages with their package managers dependencies are
-easy to add, hard to remove, and the maintenance burden grows with their
-amount. Package managers claim to take care of transitive dependencies. Which
-is convenient to the developer, but, as Corbet says, frees (or denies,
-depending how one looks at it) developers from their basic right (or
-obligation?) to understand them. "We can't understand why Kids These Days
-just don't want to live that way" -- [Jonathan Corbet, 2022 April][linux-rust].
+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 download and build the dependency
+tree, sometimes conveniently generate a "lock file", so your project has an
+illusion of being "reproducible".
 
-Here is my dependency checklist:
+C/C++ projects I've been involved usually had 1-5 non-system dependencies,
+whereas all others -- tens or hundreds. This uncovers an obvious correlation:
+if it's easy to add dependencies, they will be added. En masse. Not adding
+dependencies in Go/Python/whatever requires discipline. Slip once, add some
+crap -- it will be very hard to remove, as changing dependencies often require
+large rewrites. Not adding dependencies in C/C++, however, is the path of least
+resistance. However, in the long term, my C/C++ projects tended to survive
+longest (or required least amount of changes to build and run after the world
+moved on) just because of this.
+
+Making it easy to depend on external code is is convenient during development,
+but frees (or denies, depending how one looks at it) developers from their
+basic right (or obligation?) to understand them. And adds real long-term
+maintenance costs.
+
+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.
+
+This is why I am always hesitant to pull in code to my project, and have a my
+dependency checklist:
 
 - Obvious: does it work at all?
 - How easy is it to build, run and run it's tests?
@@ -92,8 +107,14 @@ git-subtrac shouldn't care?
 Conclusion
 ----------
 
-Can git checkout local submodules when they are in the same repository, so we
-can reconsider (of not having) a package manager for zig?
+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, 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.
 
 [git-subtrac]: https://github.com/apenwarr/git-subtrac/
 [linux-rust]: https://lwn.net/SubscriberLink/889924/a733d6630e3b5115/