4 ms·

Do I have the ability to somehow specify "use git+ssh for this dependency" with the new modules system? Right now it seems near impossible with go to do that o

Do I have the ability to somehow specify "use git+ssh for this dependency" with the new modules system? Right now it seems near impossible with go to do that other than manually cloning the repositories into the correct path. We can't host our things publicly and have to use SSH to clone the repositories at my company. It is especially frustrating in our CI/CD process if we need to manually clone our packages for setting everything up.

ereyes01 8y ago
I currently use submodules inside of vendor/ and set each dependency's remote to the SSH URL. You can then simply use git clone --recursive to get everything, including via SSH. That being said, I share your hope that this can remain smooth in the new Go modules implementation. $GOPATH is always a hurdle for new-comers to wrap their heads around in my experience.
- rukenshia 8y ago
  Definitely sounds like an upgrade to our current approach, thank you!
thwarted 8y ago
That's one thing that frustrated me about dep. go get is deficient in this area too. I understand the need to namespace packages, but requiring them to be hosted (or have metatags on a page) at the location the import path specifies in order to be able to pull them down is insanity. To make matters worse, dep tried to stuff too much of a DSL into the package specification on the command line. example.com/path/pkg@hashish made it impossible to specify git@example.com/path/pkg as the location because the parser wasn't robust enough, and the package location parser wasn't/isn't smart enough to honor ssh://git@example.com/path/path as a way to be explicit about how you wanted this done. dep did work for our use case if you edited the toml file directly, once I made a 2 character change to a regular expression in v0.3.0. We use dep and stopped upgrading with that version; I'm hoping go modules make non-public repos easier, but I'm not holding my breath.
BillinghamJ 8y ago
git config --global url.ssh://git@github.com/.insteadOf https://github.com/
- pritambaral 8y ago
  This is what we use too, but it's still magic (in a different tool) and Go shouldn't be relying on it.
  - BillinghamJ 8y ago
    I think it should actually. Go’s module system should not have to give consideration to the particular transport you want to use. Its references are canonical and it’s up to you to set up the relevant process for it to retrieve the source for those references. I get the impression that that’s what the proxy stuff is about - you’ll just set up a proxy which deals with retrieving the code.
    - pritambaral 8y ago
      > Go’s module system should not have to give consideration to the particular transport you want to use. > Its references are canonical and it’s up to you to set up the relevant process for it to retrieve the source for those references. Git has a proper notion of references; it properly separates transport from references of remotes. Go uses just `https://` https://` links, and expects the website to have a single `<meta>` tag containing a vcs clone URL (i.e., transport) to use. VCSes have had separation and multiplicity of transport for a long time, but Go will deal with only one URL (i.e., transport), with no way for the user/distributor to specify preferences otherwise. For example, everything from git.kernel.org to github.com allows the user to chose which URL to clone with. The remote is not supposed to know or dictate a single transport. I think `go get`'s limited method of transport discovery is just a hack that got released into production and stagnated in its form. It was a perfectly fine hack for public repos (on the internet or on Google's intranet), but it just never got any features (let alone documentation) specifically for repos that need an authenticated way to clone them. The fact that git has a nifty way to rewrite URLs is just a luck.
ssutch3 8y ago
I believe that is the point of the mod proxy.

ereyes01 8y ago

I currently use submodules inside of vendor/ and set each dependency's remote to the SSH URL. You can then simply use git clone --recursive to get everything, including via SSH. That being said, I share your hope that this can remain smooth in the new Go modules implementation. $GOPATH is always a hurdle for new-comers to wrap their heads around in my experience.

rukenshia 8y ago
Definitely sounds like an upgrade to our current approach, thank you!

thwarted 8y ago

That's one thing that frustrated me about dep. go get is deficient in this area too. I understand the need to namespace packages, but requiring them to be hosted (or have metatags on a page) at the location the import path specifies in order to be able to pull them down is insanity. To make matters worse, dep tried to stuff too much of a DSL into the package specification on the command line. example.com/path/pkg@hashish made it impossible to specify git@example.com/path/pkg as the location because the parser wasn't robust enough, and the package location parser wasn't/isn't smart enough to honor ssh://git@example.com/path/path as a way to be explicit about how you wanted this done. dep did work for our use case if you edited the toml file directly, once I made a 2 character change to a regular expression in v0.3.0. We use dep and stopped upgrading with that version; I'm hoping go modules make non-public repos easier, but I'm not holding my breath.

BillinghamJ 8y ago

git config --global url.ssh://git@github.com/.insteadOf https://github.com/

pritambaral 8y ago
This is what we use too, but it's still magic (in a different tool) and Go shouldn't be relying on it.
- BillinghamJ 8y ago
  I think it should actually. Go’s module system should not have to give consideration to the particular transport you want to use. Its references are canonical and it’s up to you to set up the relevant process for it to retrieve the source for those references. I get the impression that that’s what the proxy stuff is about - you’ll just set up a proxy which deals with retrieving the code.
  - pritambaral 8y ago
    > Go’s module system should not have to give consideration to the particular transport you want to use. > Its references are canonical and it’s up to you to set up the relevant process for it to retrieve the source for those references. Git has a proper notion of references; it properly separates transport from references of remotes. Go uses just `https://` https://` links, and expects the website to have a single `<meta>` tag containing a vcs clone URL (i.e., transport) to use. VCSes have had separation and multiplicity of transport for a long time, but Go will deal with only one URL (i.e., transport), with no way for the user/distributor to specify preferences otherwise. For example, everything from git.kernel.org to github.com allows the user to chose which URL to clone with. The remote is not supposed to know or dictate a single transport. I think `go get`'s limited method of transport discovery is just a hack that got released into production and stagnated in its form. It was a perfectly fine hack for public repos (on the internet or on Google's intranet), but it just never got any features (let alone documentation) specifically for repos that need an authenticated way to clone them. The fact that git has a nifty way to rewrite URLs is just a luck.

ssutch3 8y ago

I believe that is the point of the mod proxy.