From b91e5407613b3b7f59e7bb0c741f5fe359f64cc8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Motiejus=20Jak=C5=A1tys?= Date: Sat, 23 Apr 2022 16:41:58 +0300 Subject: [PATCH] wip git-subtrac --- content/log/git-subtrac.md | 89 +++++++++++++++++++++++--------------- 1 file changed, 55 insertions(+), 34 deletions(-) diff --git a/content/log/git-subtrac.md b/content/log/git-subtrac.md index 854978c..cced5fc 100644 --- a/content/log/git-subtrac.md +++ b/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 ` 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 -` 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 -`. Let's talk about auditing dependencies. +It is, howerver, harder to *add* a dependency with submodules than with, say, +`go get `. 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/