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.
> 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:
"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.
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.
