4 ms·

> GOPATH and modules mean that the tooling has to handle two different cases... No, the main thing, that GOPATH meant, is that Google (and everyone else) had t

> GOPATH and modules mean that the tooling has to handle two different cases... No, the main thing, that GOPATH meant, is that Google (and everyone else) had to make their Go libraries open-source — since entire logic of GOPATH revolves around building stuff, downloaded from Github. Once Google management decided to be serious about pushing Go to masses, they hurriedly rushed to erase GOPATH from history (just like they erased "Don't be evil" slogan from Internet after getting serious about doing business).

jen20 5y ago
...what? GOPATH has nothing to do with GitHub. It is one of the places that has special case handling, but is absolutely not the purpose of GOPATH. Case in point: the VM I have to build some legacy stuff using GOPATH does not have a _single_ dependency from GitHub. Not one. Nor does it contain any open source code, besides the standard library.
- throwaway894345 5y ago
  Yeah, the parent seems to think that GOPATH has something to do with pulling from GitHub and that modules implies some central repository which isn't the case at all. If you use modules, you're also pulling from GitHub directly in most cases, although nowadays there is a public caching proxy in the middle IIRC. And in both cases you could/can use private repositories.
- altfredd 5y ago
  Indeed, — GOPATH does not imply using Github, and Github does not imply open-source (even if it is one of the most widely used ways to host open-source). The logic of GOPATH and "go get" just so happen to revolve around building packages, fetched from source code repository. This logic used to be a stop-gap, written during early stages of Golang development, and makes it awkward (at best) to distribute proprietary Go libraries. I assume, that Google is introducing module system (and aggressively deprecating GOPATH) to work around this issue (among others).
dcow 5y ago
You don't know shit. I “hate” Go and Google with a mild passion (I mean this lightly, rhetorically) and still know enough to explain to you that modules have nothing to do with publishing binary blobs (which like isn’t even a thing in the go ecosystem) or private repos. Modules add a layer of indirection and solve so many actual problems with the GOPATH like “how do you have a dev copy with local changes and a main copy of a library on the same machine?”, “how do you manage/scope different versions of the same dependency between/to different projects?”, etc. GOPATH was so abysmally short sighted only Google could have created it.
- altfredd 5y ago
  Just checked, and looks like you are right — modules don't offer more facilities to distribute proprietary code than GOPATH already did. I stand corrected.

jen20 5y ago

...what? GOPATH has nothing to do with GitHub. It is one of the places that has special case handling, but is absolutely not the purpose of GOPATH. Case in point: the VM I have to build some legacy stuff using GOPATH does not have a _single_ dependency from GitHub. Not one. Nor does it contain any open source code, besides the standard library.

throwaway894345 5y ago
Yeah, the parent seems to think that GOPATH has something to do with pulling from GitHub and that modules implies some central repository which isn't the case at all. If you use modules, you're also pulling from GitHub directly in most cases, although nowadays there is a public caching proxy in the middle IIRC. And in both cases you could/can use private repositories.
altfredd 5y ago
Indeed, — GOPATH does not imply using Github, and Github does not imply open-source (even if it is one of the most widely used ways to host open-source). The logic of GOPATH and "go get" just so happen to revolve around building packages, fetched from source code repository. This logic used to be a stop-gap, written during early stages of Golang development, and makes it awkward (at best) to distribute proprietary Go libraries. I assume, that Google is introducing module system (and aggressively deprecating GOPATH) to work around this issue (among others).

dcow 5y ago

You don't know shit. I “hate” Go and Google with a mild passion (I mean this lightly, rhetorically) and still know enough to explain to you that modules have nothing to do with publishing binary blobs (which like isn’t even a thing in the go ecosystem) or private repos. Modules add a layer of indirection and solve so many actual problems with the GOPATH like “how do you have a dev copy with local changes and a main copy of a library on the same machine?”, “how do you manage/scope different versions of the same dependency between/to different projects?”, etc. GOPATH was so abysmally short sighted only Google could have created it.

altfredd 5y ago
Just checked, and looks like you are right — modules don't offer more facilities to distribute proprietary code than GOPATH already did. I stand corrected.