[pdonis]

> Most of these examples don’t automatically fetch the dependencies.

Quite frankly, I don't want to automatically fetch dependencies at the same time I am running the code. IMO those should be separate steps, and combining them together in one is not a good idea.

[codegeek]

Why not ?

[pdonis]

Because I don't want the code I'm running to change out from under me when I tell it to run because some dependency got updated (or for any other reason, for that matter). That's a recipe for disaster.

Running the code is a separate step from determining what code I am going to run; the latter includes determining exactly what versions of all dependencies I am going to run. The two should not be combined.

[codegeek]

But the versions are locked right ? Similar to what package-lock.json etc does. So whats the issue ?

[pdonis]

If the versions are locked, then after the first download, nothing should be downloaded again unless I explicitly change a requirement and/or a version. So after the first time with a given set of requirements and versions, I suppose "go run" would be fine since it won't actually download anything.

But for that first time, I still want to separate the two steps, for the reasons I've given elsewhere in this discussion.

[_ache_]

What happens when the dependency are updated and not compatible anymore ?

[teejays]

Dependencies won’t update themselves since they are locked to their versions. If the developer manually triggers an update, and the dependencies aren’t compatible, either the code wouldn’t compile or it’s behave weird. In both cases, what’s the advantage of separating out the fetch-dependencies part?

[vaughnegut]

That's why you have a go.mod file that specifies the dependencies for you. Just run go mod tidy and it generates/updates it for you. You get these reproducible builds for free this way.

[mseepgood]

A Go module specifies the exact versions of its dependencies. These versions do not change unless the author explicitly updates them.

[cpuguy83]

"go mod download && go run ."

What's the point in making `go run` error out when it already knows what dependencies to get and how to get them.

[pdonis]

> "go mod download && go run ."

No: "go mod download" if I want to update dependencies; then look to see what got updated and how it will affect what I'm doing. Then "go run".

> What's the point in making `go run` error out when it already knows what dependencies to get and how to get them.

Because I don't care what "go run" knows. I care what code is going to run when I say "go run". I want that code to be the code I already know is there and understand. I don't want it to be some new code that "go run" downloads because it sees that an update to a dependency is available. Downloading that update and understanding what effects it has is something that I want to do before "go run", not as part of it.

[cpuguy83]

That is the purpose of go.mod/go.sum. `go mod download` never updates anything unless you change go.mod.