Go's old $GOPATH story for development and dependencies

Re:Go's old $GOPATH story for development and dependencies by dfawcus on Friday May 24, 2024 @06:56AM (#40464852)

> 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.

[ Parent | on HN ]

Re:Go's old $GOPATH story for development and dependencies by guilherme-puida on Friday May 24, 2024 @07:54AM (#40465217)

> 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/d...

[ Parent | on HN ]

Re:Go's old $GOPATH story for development and dependencies by vetrom on Friday May 24, 2024 @10:23AM (#40466580)

They 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#embe...)

[ Parent | on HN ]