|
|
|
|
|
by chimeracoder
4575 days ago
|
|
Genuine curiosity: In practice, which Go packages that people use require conflicting versions, necessitating a use for this tool? In my experience, Go developers are generally good about building against updated versions of packages. Combining that with the fact that binaries are all compiled and statically linked (as opposed to dynamically linked or interpreted), I can't remember ever running into the problem where packages X and Y (that I both need) each depend on different versions of Z. A big advantage of virtualenv in Python isn't relevant here: the ability to specify a specific version of Python (not just 2 vs. 3, but minor versions as well). With Go, you should always be using the most recent version[0] of gc or gccgo, as there is no reason not to. [0] (If you are someone who actually needs two different versions of the Go gc compiler installed on your system, you're probably on the core dev team, which means you already know what you're doing and already avoid these tools for other reasons.) |
|
It's kind of a pain jumping around distributions manually, which is why I use Gobrew to manage my goandroid Go environment and my normal Go environment.