Hacker News Reader

Comment by lelandbatey | Hacker News Reader

Even easier than that, you can use the 'replace' statement in your go mod to change where the Go build system will try to pull the dependencies from; you can point to a folder on disk or to another forge, and if you want total control you can indirect everything to your own artifact cache via GOPROXY (which can be something as simple as a static folder of source code).

The "module name is network path" is a convenient convention but not at all some "limitation" of the tooling.

View on HN

> you can use the 'replace' statement in your go mod to change where the Go build system will try to pull the dependencies from

Heads up for anyone who doesn't know: this only works at the "top level". Any replace directives in your dependencies will be ignored[1].

So for example if you have a dependency tree like [main -> thirdpartyframework -> golang.org/x/net/http2], and thirdpartyframework uses a vulnerable version of `golang.org/x/net/http2`, you can't just fix it by patching the thirdpartyframework repository with a replace directive; no, because that would be too convenient. Instead, the replace directive needs to be at the main module, where it doesn't make sense and is inconvenient.

Even though I like Go, it really seems like they don't care about anything other than monorepos. As soon as you need to work with forks, mirrors, or even just private modules[2][3], the tooling actively works against you. Also using your custom module proxy is a pain.

[1] See: https://go.dev/ref/mod#go-mod-file-replace:~:text=replace%20...

[2]: If you've only used private modules hosted on GitHub you might not have noticed too much pain because the Go tooling has hardcoded behavior specifically for GitHub and a few mainstream forges. You don't find out about this until you try to self-host something like Forgejo on your own domain thinking it would Just Work(tm), but it doesn't, and now you're left wondering why tf it works with GitHub but not with your own forge instance.

[3]: I think there's no hardcoded code for SourceHut, so you might be able to experience the inconvenience by hosting private modules in there.

> Instead, the replace directive needs to be at the main module, where it doesn't make sense and is inconvenient.

Wait, what? If you decide, in your own application, to force all your dependencies to use a specific version of golang.org/x/net/http2, then obviously you'd want to be able to put this directive into your own application's source instead of going around patching 3rd-party repositories (that's just rude).

And now all your source files contain URLs to abandoned infrastructure. Is that what you'd want long term?

How's that any different from java code using package names starting with com.sun?

com.sun is an identifier, nothing more. No tooling sees com.sun and assumes, "oh that means I can make an HTTP request to the IP address which sun.com resolves to".

In Go, the package identifiers are literally URLs. Go's own tooling assumes that it can make an HTTP request to the URL and that the response will be HTML with particular tags which Go's tooling will parse and use to resolve a git repository which can be 'git clone'd. Leaving them as-is when you abandon the infrastructure they reference literally means leaving dead links in your source code.

If it's not fetching from the URL then it's not really a URL, just an identifier that looks like a URL.

What do you mean? Go's tooling definitely tries to fetch from that URL.

Not if you tell it a different URL though

That's just the default, which you can easily override if you need to. IMO there is nothing wrong with treating Go package names as arbitrary identifiers like com.sun.* If you're spending a lot of time updating imports because the underlying repo has moved from its original URL, then just don't do that. It's unnecessary.

And leave URLs to abandoned infrastructure all over the place? No thank you.

Sounds like classic developer OCD to me. Old URLs used as Go package identifiers are completely harmless.

Until your tooling automatically makes a request to a now-untrusted server and trusts its response...

The Go tooling won't do that if you configure it properly (e.g. via a 'replace' directive in your go.mod or https://go.dev/ref/mod#goproxy-protocol)

Any tool that automatically assumes that a URL in a Go module import is 'trusted' is just a broken tool.

And if any tooling ever gets executed without the proper replace directive...

Any tooling that looks at Go module imports should respect the contents of go.mod.

If you haven't added a replace directive to your go.mod, then you certainly haven't replaced all instances of the old URLs with updated ones.

Go mandates lockfiles, called go.sum

It's a solution that keeps you working now and you can do the actual search and replace when scheduling allows.

AKA it solves nothing, just kicks the problem down the road.

welcome to fast moving companies.

Reply on news.ycombinator.com