[rukenshia]

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.

[thwarted]

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 [e-mail]/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://[e-mail]/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]

    git config --global url.ssh://[e-mail]/.insteadOf https://github.com/

[pritambaral]

This is what we use too, but it's still magic (in a different tool) and Go shouldn't be relying on it.

[BillinghamJ]

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]

> 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://` 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.

[BillinghamJ]

Bear in mind, Go doesn't just support git... so HTTP and SSH aren't the only options.

[pritambaral]

> Go doesn't just support git

I didn't claim Go supports only git.

> so HTTP and SSH aren't the only options.

My entire point is that VCSes support multiple transports since before Go came about. I never claimed Go should support HTTP and SSH only. In fact, I never claimed it should support either. I claimed it shouldn't force the VCS host to chose for the user which clone URL (and thus transport) to use.

[bdhess]

It’s hardly magic. It’s a defined feature of git. If one couldn’t avail himself of the defined features of git, then there’d be no reason to build on top of it in the first place.

[pritambaral]

> If one couldn’t avail himself of the defined features of git, then there’d be no reason to build on top of it in the first place.

Sure build on top of it, but don't expect your users to implicitly know the defined, yet obscure, features of git you build on.

> It’s hardly magic.

I didn't claim this is a magic feature in git. I meant the way of `go get`-ing a private library by letting `go get` try and clone from https URLs while silently changing them to git:// URLs in a completely separate layer under it is magic.

[majewsky]

> Sure build on top of it, but don't expect your users to implicitly know the defined, yet obscure, features of git you build on.

That's what documentation is for. Every application should be documenting (e.g. in README.md) how it can be built.

[pritambaral]

How is the first application developer to know this git (not go) feature exists in the first place? The application developer is looking to use `go get`, and is frustrated that `go get` only downloads via https, asking them for a username and password combo every time. `go get` has no documentation to make it use git URLs.

Only when the application developer looks online for a solution to this do they find some StackOverflow post detailing this workaround. Or other workarounds, like the insecure option of telling git to save your https credentials.

Sure, a knowledgeable application developer can put whatever quirks their build system needs in their documentation; but a developer ignorant of these workarounds shouldn't have to go beyond `go get`'s documentation in the first place.

[jonathanoliver]

For BitBucket:

git config --global url.ssh://[e-mail]/.insteadOf https://bitbucket.org/

[ereyes01]

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]

Definitely sounds like an upgrade to our current approach, thank you!

[ssutch3]

I believe that is the point of the mod proxy.