6 ms·

I'm in favor of firming up the roles of `go get` and `go install`--it was damn weird that running `go get github.com/foo/bar` did one thing inside a Go project

by floren 5y ago

I'm in favor of firming up the roles of `go get` and `go install`--it was damn weird that running `go get github.com/foo/bar` did one thing inside a Go project and another outside it. Growing pains of the introduction of Go modules and the deprecation of GOPATH and what-not. My bigger complaint, though, is that the Go team have decided to ignore replace directives when you call `go install`. In a perfect world, I find a bug in an upstream library, submit a fix, and they accept it. In practice, lots of upstream maintainers check their issue/PR lists about once a month if you're lucky, so the best way to temporarily fix the problem is to put in a replace directive changing github.com/foo/bar -> github.com/me/bar until the PR goes in. Except `go install` will ignore that, so if you install a tool via `go install` you get the broken library, but if you git clone the repo and run `go build`, you get the fix. In proper Go team fashion, they have declared that because sometimes replace directives are difficult, they refuse to deal with them at all--if you intend to distribute something for use with go install, you better fork the dependency and update all your source files.

pa7ch 5y ago
'go install pkg@version' will error on replace directives rather then ignore. I fought hard in the github issues to make go install error on replace as a compromise to ignoreing it which creates two subtly different build modes! Also by erroring we leave open the possibility to eventually change it to build correctly with the replace directives without breakage. Add your voice that @version cmds should respect all replace directives that they reasonably can!
- floren 5y ago
  Thank you for the correction, and thank you for fighting for it! I agree that errors are far better than silently ignoring it. I'll weigh in on the issue tracker if I remember later.
sudhirj 5y ago
In the interest of fairness, shouldn't this finish with: > In proper Go team fashion, they have declared that because sometimes replace directives are difficult,... they've asked for proposals that can be publicly vetted and discussed? The line has been "submit a proposal, let's review it" as long as I can remember.
- dcow 5y ago
  meh. It’s just the same response by a different color: the hard and useful problem doesn't get solved since google avoids it with mono repo meanwhile everyone writing real open source software has to endure half baked garbage until some future proposal comes around and attempts to clean up the mess. Turns out it’s still hard so let’s write another tool, that should fix it! More deflection and proposals ensue on the new tool.
jrockway 5y ago
I think what we need is a tool for properly forking upstream modules and adjusting the dependencies accordingly (and of course, the adjustment can be undone when/if the upstream maintainer accepts and merges your change). Replace is problematic in many ways: 1. It doesn't propagate downstream. If module Z depends on module Y, and module Y depends on module X, and module X is faulty, it's logical for module Y to have a replace directive for a fixed version of module X. This does not affect module Z, which now subtly (or loudly, sometimes) breaks. That helps nobody. It's good if you have an application that you build in CI and ship to your own private servers, but pretty much useless for everyone else. (And people don't seem aware of this; the author of module Y thinks they've fixed the problem for their consumers, but hasn't.) 2. It doesn't compose. If module Z depends on module Y and module X, and module Y and module X depend on module W, and the authors of module X and module Y independently discover that module W is broken and develop separate fixes for it, the author of module Z really has no option to make their software work. I think Rob Pike's "a little copying is better than a little dependency" is apt here. If you just copy the source code you want into your own application, the problem goes away. But, the problematic upstream dependencies are often large projects (Azure's API client is a big offender here; I've never successfully depended on it without a replace directive) that are impractical to simply copy-and-refactor. At some point, these upstream providers need to fix their shit or risk not being used. This problem, by the way, is not unique to Go. I notice this problem come up with Javascript when a bunch of modules depend on faulty-module-0.0.1 with a security problem. faulty-module-0.1.0 is released with a fix for the security problem, but your app directly depends on neat-feature-1.2.3 and nifty-addon-23.47.1 and those modules break with faulty-module-0.1.0. So inevitably you show up at the issue tracker for neat-feature and nifty-addon where 6000 other people are yelling at the authors to release a version that depends on the fixed version of faulty-module, find that the authors aren't around, and are just sad because there's nothing you can do. Basically, depending on other people's software sucks, and so does copying their code into your application. go has the advantage of very clearly telling you "hey, you're fucked!" which annoys people, but you basically get into this situation no matter what programming language you use. It's just you might not know, which is scary. (I hope you use something like Sentry for your Javascript apps and have 100% test coverage.)

by floren 5y ago

pa7ch 5y ago

'go install pkg@version' will error on replace directives rather then ignore. I fought hard in the github issues to make go install error on replace as a compromise to ignoreing it which creates two subtly different build modes! Also by erroring we leave open the possibility to eventually change it to build correctly with the replace directives without breakage. Add your voice that @version cmds should respect all replace directives that they reasonably can!

floren 5y ago
Thank you for the correction, and thank you for fighting for it! I agree that errors are far better than silently ignoring it. I'll weigh in on the issue tracker if I remember later.

sudhirj 5y ago

In the interest of fairness, shouldn't this finish with: > In proper Go team fashion, they have declared that because sometimes replace directives are difficult,... they've asked for proposals that can be publicly vetted and discussed? The line has been "submit a proposal, let's review it" as long as I can remember.

dcow 5y ago
meh. It’s just the same response by a different color: the hard and useful problem doesn't get solved since google avoids it with mono repo meanwhile everyone writing real open source software has to endure half baked garbage until some future proposal comes around and attempts to clean up the mess. Turns out it’s still hard so let’s write another tool, that should fix it! More deflection and proposals ensue on the new tool.

jrockway 5y ago

I think what we need is a tool for properly forking upstream modules and adjusting the dependencies accordingly (and of course, the adjustment can be undone when/if the upstream maintainer accepts and merges your change). Replace is problematic in many ways: 1. It doesn't propagate downstream. If module Z depends on module Y, and module Y depends on module X, and module X is faulty, it's logical for module Y to have a replace directive for a fixed version of module X. This does not affect module Z, which now subtly (or loudly, sometimes) breaks. That helps nobody. It's good if you have an application that you build in CI and ship to your own private servers, but pretty much useless for everyone else. (And people don't seem aware of this; the author of module Y thinks they've fixed the problem for their consumers, but hasn't.) 2. It doesn't compose. If module Z depends on module Y and module X, and module Y and module X depend on module W, and the authors of module X and module Y independently discover that module W is broken and develop separate fixes for it, the author of module Z really has no option to make their software work. I think Rob Pike's "a little copying is better than a little dependency" is apt here. If you just copy the source code you want into your own application, the problem goes away. But, the problematic upstream dependencies are often large projects (Azure's API client is a big offender here; I've never successfully depended on it without a replace directive) that are impractical to simply copy-and-refactor. At some point, these upstream providers need to fix their shit or risk not being used. This problem, by the way, is not unique to Go. I notice this problem come up with Javascript when a bunch of modules depend on faulty-module-0.0.1 with a security problem. faulty-module-0.1.0 is released with a fix for the security problem, but your app directly depends on neat-feature-1.2.3 and nifty-addon-23.47.1 and those modules break with faulty-module-0.1.0. So inevitably you show up at the issue tracker for neat-feature and nifty-addon where 6000 other people are yelling at the authors to release a version that depends on the fixed version of faulty-module, find that the authors aren't around, and are just sad because there's nothing you can do. Basically, depending on other people's software sucks, and so does copying their code into your application. go has the advantage of very clearly telling you "hey, you're fucked!" which annoys people, but you basically get into this situation no matter what programming language you use. It's just you might not know, which is scary. (I hope you use something like Sentry for your Javascript apps and have 100% test coverage.)