100 lines
4.1 KiB
Markdown
100 lines
4.1 KiB
Markdown
|
---
|
||
|
|
title: "git-subtrac met andrewrk"
|
||
|
|
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.
|
||
|
|
|
||
|
|
git submodules meet andrewrk
|
||
|
|
----------------------------
|
||
|
|
|
||
|
|
I use [`git-subtrac`][git-subtrac] for some of my projects, and was 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".
|
||
|
|
- 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."
|
||
|
|
- 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
|
||
|
|
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
|
||
|
|
-----------------
|
||
|
|
|
||
|
|
[`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.
|
||
|
|
|
||
|
|
It is, howerver, harder to *add* a dependency than with, say, `go get
|
||
|
|
<dependency>`. Let's talk about auditing dependencies.
|
||
|
|
|
||
|
|
Auditing 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].
|
||
|
|
|
||
|
|
Here is my dependency 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.
|
||
|
|
|
||
|
|
Zooming into the last part: C projects tend to do it well. For Go and Python
|
||
|
|
projects a small number of dependencies is often a sign of care and quality on
|
||
|
|
other areas, too. [mattn/go-sqlite3](https://github.com/mattn/go-sqlite3),
|
||
|
|
[google/brotli](https://github.com/google/brotli),
|
||
|
|
[apenwarr/redo](https://github.com/apenwarr/redo),
|
||
|
|
[cmph](http://cmph.sourceforge.net/) are good examples.
|
||
|
|
|
||
|
|
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).
|
||
|
|
|
||
|
|
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?
|
||
|
|
|
||
|
|
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?
|
||
|
|
|
||
|
|
[git-subtrac]: https://github.com/apenwarr/git-subtrac/
|
||
|
|
[linux-rust]: https://lwn.net/SubscriberLink/889924/a733d6630e3b5115/
|