5 ms·

There are definitely good things about googles "decentralized package management". But using a url for the import also causes problems. What if the url the code

by thayne 7y ago

There are definitely good things about googles "decentralized package management". But using a url for the import also causes problems. What if the url the code is hosted on needs to change? And then I also ran into a case where I wanted to fork a dependency of a project, so I could get a bug-fix that hadn't been merged into upstream yet. But the only way I could figure out how to get it working was not only to have to change all of the imports in the main project, but a bunch of imports in the dependency as well to point to the fork. This seems needlessly painful.

PhilippGille 7y ago
> I wanted to fork a dependency of a project, so I could get a bug-fix that hadn't been merged into upstream yet. [...] change all of the imports in the main project, but a bunch of imports in the dependency as well to point to the fork. Isn't this solved with Go modules and the `replace` keyword in the go.mod file? It's meant to be used for exactly this purpose and the wiki uses the fork example as well: https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive https://github.com/golang/go/wiki/Modules#when-should-i-use-...
didibus 7y ago
Are we all going to pretend like we forgot Java has been using URIs for imports for 20+ years?
- masklinn 7y ago
  The difference is that java’s “uris for import” is nothing more than a namespacing convention to avoid conflicts. A url in go is the actual place where `go get` will go retrieve the dependency, and the directory it’ll live at.
  - didibus 7y ago
    That's true, thinking from that angle it does seem more troublesome then, in cases where the URI goes down, or changes, or you need a personal fork.
eeZah7Ux 7y ago
"decentralized package management" is a security dumpster fire. I want well-known Linux distributions to review and vet libraries - as they do - so that I don't have to trust some random libraries from random author hosted on random VCS services.

by thayne 7y ago

PhilippGille 7y ago

> I wanted to fork a dependency of a project, so I could get a bug-fix that hadn't been merged into upstream yet. [...] change all of the imports in the main project, but a bunch of imports in the dependency as well to point to the fork. Isn't this solved with Go modules and the `replace` keyword in the go.mod file? It's meant to be used for exactly this purpose and the wiki uses the fork example as well: https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive https://github.com/golang/go/wiki/Modules#when-should-i-use-...

didibus 7y ago

Are we all going to pretend like we forgot Java has been using URIs for imports for 20+ years?

masklinn 7y ago
The difference is that java’s “uris for import” is nothing more than a namespacing convention to avoid conflicts. A url in go is the actual place where `go get` will go retrieve the dependency, and the directory it’ll live at.
- didibus 7y ago
  That's true, thinking from that angle it does seem more troublesome then, in cases where the URI goes down, or changes, or you need a personal fork.

eeZah7Ux 7y ago

"decentralized package management" is a security dumpster fire. I want well-known Linux distributions to review and vet libraries - as they do - so that I don't have to trust some random libraries from random author hosted on random VCS services.