4 ms·

For projects with all dependencies hosted on github. I still need to work out if I can use the new tooling with our internal repos. I imagine I'll need to be ed

For projects with all dependencies hosted on github. I still need to work out if I can use the new tooling with our internal repos. I imagine I'll need to be editing that go.mod file.

josteink 8y ago
So not only are modules tightly coupled to a specific version control system (git), it’s also tied to a single centralized online service of this decentralized VCS. Maybe I’m just old fashioned, but to me this is a code smell. It reeks of needless coupling, and I suspect one day (sooner rather than later) the golang designers will come to regret it. To top it off, despite being tied to a VCS, it seems to lack a useful means of enforcing versioned dependencies. This simply does not look like a good design. Is this really the new and improved version? If so, how god awfully bad was the previous iteration?
- cube2222 8y ago
  I had no problems using it with self hosted gitlab.
- jchw 8y ago
  It is not tied to Git nor GitHub.
  - e12e 8y ago
    So when you're building on a host without internet access, the "github.com" namespacing isn't an issue?
    - jchw 8y ago
      Depends. If you use vendoring, which is supported by Go modules, then you should be able to avoid needing any internet access. If you want to grab the dependencies fresh, then obviously if you have a github dependency, it will require git and the ability to access GitHub.com.
    - deleted 8y ago
      [deleted]
- stubish 8y ago
  It won't be tied to a single VCS or centralized service. It will support everything 'go get' does, which is several different VCS systems and I think all popular public hosting providers. The trick is getting code from secured, private repos, which takes a varying amount of effort (eg. set up firewall rules and a web server on the domain name you are using in your import paths to return the magic headers to inform 'go get' that it actually needs to use ssh and where on the remote filesystem to go)

For projects with all dependencies hosted on github. I still need to work out if I can use the new tooling with our internal repos. I imagine I'll need to be editing that go.mod file.

josteink 8y ago

So not only are modules tightly coupled to a specific version control system (git), it’s also tied to a single centralized online service of this decentralized VCS. Maybe I’m just old fashioned, but to me this is a code smell. It reeks of needless coupling, and I suspect one day (sooner rather than later) the golang designers will come to regret it. To top it off, despite being tied to a VCS, it seems to lack a useful means of enforcing versioned dependencies. This simply does not look like a good design. Is this really the new and improved version? If so, how god awfully bad was the previous iteration?

cube2222 8y ago
I had no problems using it with self hosted gitlab.
jchw 8y ago
It is not tied to Git nor GitHub.
- e12e 8y ago
  So when you're building on a host without internet access, the "github.com" namespacing isn't an issue?
  - jchw 8y ago
    Depends. If you use vendoring, which is supported by Go modules, then you should be able to avoid needing any internet access. If you want to grab the dependencies fresh, then obviously if you have a github dependency, it will require git and the ability to access GitHub.com.
  - deleted 8y ago
    [deleted]
stubish 8y ago
It won't be tied to a single VCS or centralized service. It will support everything 'go get' does, which is several different VCS systems and I think all popular public hosting providers. The trick is getting code from secured, private repos, which takes a varying amount of effort (eg. set up firewall rules and a web server on the domain name you are using in your import paths to return the magic headers to inform 'go get' that it actually needs to use ssh and where on the remote filesystem to go)