On Mon, Oct 15, 2018 at 12:40:18PM +0200, Pierre Neidhardt wrote:
> No, Go programs typically refer only to repositories, not to their commit.  This
> is precisely why it's a problem.  Golang's dependency management was not very
> well designed I'm afraid.
> 
> Misunderstanding?

I think you and Ludo talked past each a bit. To clarify:

Go code refers to dependencies by the URL of their repositories. For
example, the code will import the modules it depends on like this:

------
import ("github.com/thejerf/suture"
        "github.com/rcrowley/go-metrics")
------

The Go compiler will actually fetch these Git repos if they are not
already available locally, cloning and using the HEAD commit (?!).

But in practice, any complex Go software will use a dependency
management tool that also specifies the Git commit to use, because...

... there is basically no concept of "releases" or "stable APIs" in Go
world, although there are 3rd party tools that try to fill the gap.
Since nobody is thinking about releasing or maintaining an API, they
don't, and it becomes important to use the right Git commit.

My opinion is that we should use the "correct" Git commit every time,
even it means we have to package several versions of the same Go
library, or use channels, or Scheme macros, etc. Otherwise we will have
a lot of debugging to do, and upstream developers will start to resent
us when they get bug reports. With Guile, we have the tools to achieve
this. I've been doing it "manually" for the Syncthing package.

We discussed this previously:

https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00030.html