Issue
To understand this Go question need to understand the gist of Go modules Debian packaging a bit first. Basically, the Go module Debian packages are so designed that they can only be used by Debian packages themselves, but not for our daily Go import.
However, because they are just files within my OS file system, there are surely ways that we can make use of the Debian packages in our daily Go import. Has anyone successfully done that before?
The reason I'm asking is that, there are many many github repos that contains HUGE modules, but what I want is only a tiny/small portion of it, while that portion happens to have already been packed as a Debian package. I.e., using go get will get me huge code base that I mostly don't need, while apt get can get me just what I need, if I can make use of it.
Solution
AFAIK, you need to append /usr/share/gocode to your GOPATH environment variable (after your own private Go workspace, separated by :) to make those packages available to the go toolchain.
Please refer to this guide (and look at what dpkg -L outputs for any installed Go library package of interest — you'd see the package's import path be actually located under /usr/share/gocode/src).
(To expand on what @Flimzy suggested in their comment to the original post, and @JimB expanded in theirs…)
You might need to clearly state for yourself what is your intent when you're developing.
The "problem" is that there exists certain disconcert in the approaches Debian and Go take to manage dependencies:
The common practice suggested by the Go community is to either fix particular versions of your dependencies (these days — via go modules) and let the toolchain fetch and install them for you, or vendor your dependencies — which is logically the same, but in this case you actually carry these dependencies as a part of your codebase (they just sit in a specific directory).
The former is suggested for library code and generally code which is made available for reusing by third parties, while the latter is typically used by "final" products (usually developed in-house).
The approach taken by Debian is that of integration: they understandably reject the idea of uncontrolled embedding of the dependencies and try to make sure everything which is "reverse-dependent" by anything else is properly packaged, and ideally only a single version of a given library exists in any particular OS release (this is not always possible in real life, though).
Neither of the approaches is ultimately "correct" because they cater for different use cases.
An important thing to consider is that most (if not all) teams writing industry code in Go treat the underlying OS as a boring implementation detail — like, say, a blob of "something" which is not too interesting and is merely needed to run the target product (these days, this approach is taken to the extreme through the use of containers) and manage their dependencies themselves.
Why is that?
This is a philosophical question. I think this mostly boils down to the general lack of properly-skilled people in enterprises to do proper integration with the target platform, and at the same time — the ease of maintaining your own tried and tested versions of your dependencies, and not those provided by the distro.
Now let's look at the Debian-packaged Go libraries from another ange.
The Debian packagers solve their integration-centric task by wrapping Go library packages in a way wich makes them available to the Debian's build helpers (see dh-golang). That is, in Debian, when you prepare a package of some program written in Go, you would inevitably use that dh-golang thing which makes sure the Go toolchain is called in a way it could make use of the installed packages.
Now consider that quite a sizeable proportion of Go library code, and many runnable programs are platform-agnostic, and if you write Go code which is intended to be of general use, and will hence be published somewhere (like on some of the popular Git hosting solutions), it's much better to keep the code organized in a way that any developer could just grab it and be able to work on it without any special preparations.
So, what I'm leading you to, is that unless you're writing code which will certainly be only used within Debian, your approach might to be correct but if you're writing "regular" Go code, I'd recommend to separate the "writing+maintaining code" and "Debian integration" tasks — that is, write your code the way Go community recommends, and then write Debian package which makes use of the installed dependencies.
Note that for the latter you might first need to actually package all the missing dependencies.
Answered By - kostix Answer Checked By - Dawn Plyler (WPSolving Volunteer)
