2 ms·
> Is he implying that using vendor packages is more clear that using version tags in a go.mod? That would certainly be the first I’ve ever heard of someone pref
by dfawcus 2y ago
> Is he implying that using vendor packages is more clear that using version tags in a go.mod? That would certainly be the first I’ve ever heard of someone preferring dependency management via vendor packages over a go.mod & ‘go get’.
Isn't it the case that Debian builds of go 'packages' (i.e. making a .deb package') are using the pre modules mechanisms? If so, then they would seem to prefer it for some reason.
- guilherme-puida 2y ago> Isn't it the case that Debian builds of go 'packages' (i.e. making a .deb package') are using the pre modules mechanisms? As far as I know, yes: https://salsa.debian.org/go-team/packages/dh-golang/-/blob/debian/sid/lib/Debian/Debhelper/Buildsystem/golang.pm?ref_type=heads#L361 https://salsa.debian.org/go-team/packages/dh-golang/-/blob/d...
- vetrom 2y agoThey prefer it for a number of reasons, for better or worse. The big reasons I usually call out are: - packages should be buildable without calling out to any network resources. (this is the primary reason Debian dh-make-golang disables 1.11 style gomod support) - Debian specifically avoids vendored copies of code. This does create functionality and miantenance challenges, but it also produces a leaner installed code base. One again, for better or worse, this is a standing part of Debian package policy and warts from this particular choice stand out all over, not just golang. (newer Debian python, for example outright disables pip for non-venv python) There are other nits and warts that become apparent, but I think those all waterfall out from the two points I've called out here. (The Debian package policy in question: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies https://www.debian.org/doc/debian-policy/ch-source.html#embe...)