1
Fork 0
jakstys.lt/content/log/git-subtrac.md

100 lines
4.1 KiB
Markdown
Raw Normal View History

2022-04-23 07:40:29 +03:00
---
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/