|
NickPlowswell posted:I don't really see how using go get doesn't satisfy people. If I recall correctly one of Go's goals is to make everything backwards compatible and it is adapted by pretty much all major packages. Having to import "github.com/randomfuckehead/shittylibrary/awfulsublibrary" is both ugly and extremely fragile, even with go get. If randomfuckhead takes down shittylibrary or even leaves github altogether, you have to figure out what to do for future deployments. It's saved there locally with you having used go get during development, but it won't work anymore on new machines after his project/whole github is down. e: and yes I know you can locally clone it and store it yourself but that seems to be frowned upon since for whatever reason you include fragile source URIs directly in your source code.
|
#
¿
Sep 30, 2014 21:16
|
|
|
|
| # ¿ Apr 29, 2024 01:45 |
|
|
Bozart posted:Also, they aren't urls in the imports, they are file paths relative to $GOROOT. They are only interpreted as urls by the go tool. Yes, which devs then rely on the tool to use to fetch the code from the url and then compile it to use as a library that is placed in an identicaly named sub-directory in $GOPATH. I mean, to the compiler it's treated as just another plain import path, but that's not why it's bad. It's bad because it's treated as an actual content source by the built in dependency manager, and it's way too fragile and dumb of an idea.
|
|
#
¿
Oct 1, 2014 07:08
|
|