3 ms·
At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presum
by mwcampbell 13y ago
At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.
- nknighthb 13y agoGoogle's internal developers operate in a vastly different world from the one most of us are used to, always building from the head of a single, massive Perforce repository. When your world enforces the assumption that the latest version of a dependency is stable and compatible, 'go get' is a perfectly reasonable solution.
- wtbob 13y ago> At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies. That's how 'go get' works.
- TylerE 13y agoNo it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull.
- wtbob 13y ago> No it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull. You get the dependency at a version control level, at a known-good version (because you pulled from the master branch) at the time you pulled, and after that it's up to you to update it.
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]