|
|
|
|
|
|
by dfawcus
759 days 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. |
|
|
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#embe...)