For any repo that is pure SSH and HTTP/S is not an option it would seem a step forward.

See also: gomods/athens#1450

What exactly was the problem with attempt # 2? It's true that you need an explicit .git suffix in that case, but that support is documented (go help importpath) and it seems like a reasonable tradeoff in order to avoid an HTTPS resolver.

The idea is that the location of each path should be unambiguous without additional configuration. The proposed GOVCSEXT violates that property.

@bcmills Thanks for looking this over and for your reply. It's just a potential user experience issue. It might not be intuitive that the suffix is needed in these cases and some might opt for special configuration if it was available to avoid needing to include the suffix across all their modules. One reason for this would be to maintain more consistency between public and internal module paths, where having different host prefixes makes sense but needing to add the suffix when both are Git for example might not.

In some cases the module path without the suffix may be unambiguous, and consistent with how users access the repository in a browser or through their (git) client. In these cases I'm wondering if it's less about the ambiguity of the path and more about the current capabilities of the dynamic discovery implementation and the existing hints (common hosts, known suffixes) that Go uses to associate imports with the right backend client, and whether there's any opportunity for improvement without violating tooling/language principles.

Would using GOPRIVATE as above be any more appropriate since it's already being used during the import process?

If my vcs is using a specific port(see #38213), and ssh is unvailable, maybe I could add vcs path

// YourGit
{
  prefix: "yourgit.com/",
  regexp: lazyregexp.New(`^(?P<root>yourgit\.com)(/[\p{L}0-9_.\-]+)*$`),
  vcs:    "git",
  repo:   "https://{root}:19547",
  check:  noVCSSuffix,
},

to

So, configurable extra vcs path maybe reasonable at this situation

I think this proposal is a great idea. I was actually about to open an issue about the same thing. As I was reading through this issue I managed to get it working thanks to trying different ways to add the .git extension to the import path.

However, I still think this would be a good idea.

VCS platforms like Gitlab have historically had trouble with go get and allowing users to override the tooling would make a lot of those issues disappear.

Allowing users to override the tooling would also fragment the ecosystem, at least for public packages, because not everyone would know to override the tooling. (See also #38964 (comment).)

Is the .git extension not working?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Hi thanks for picking this up and considering. The .git extension does work but it needs to be included in the module import path across all files and repos. That's consistent with docs so this would be a new feature. The goal is to provide an additional mechanism to signal the vcs system without requiring inclusion of the .git extension. Understand the portability concerns. The use case here is for development teams that are sharing private modules through internal repo servers and would choose such an alternate approach even if it meant requiring their developers to customize their environment to accommodate the configuration.

for development teams that are sharing private modules through internal repo servers and would choose such an alternate approach even if it meant requiring their developers to customize their environment to accommodate the configuration.

In this case it is probably even easier to set up an HTTP redirector serving the custom domain meta tags.

In this case it is probably even easier to set up an HTTP redirector serving the custom domain meta tags.

Sorry @rsc - I think you overestimate capability of a smallish dev team to push through all the approvals and frictions in a not-dev-oriented enterprise to have anything like this done. Each interaction with IT in medium-large organizations is an uphill battle that nobody enjoys. Making a go.mod.local file (for example) or changing something in a environment is incomparable easier.

(maybe a bit out of scope for a current discussion, but please allow me to run with an idea - if Go's tooling would have a capability to have go.*.local files to augment/override corresponding parts in go.*' files, it might go a long way to help in a scenario like "checkout repo, have gitignore line for go.*.local, have go.*.local files produced by manually or by script, then commit changes without need to exclude your local env overrides every time.'. )

Talked to @jayconrod, @bcmills, @matloob. It sounds like this general need fits into the overall enterprise authentication question, and maybe a broader solution would be better. That said, we don't know what the broader solution is either.

The .git extension does work but it needs to be included in the module import path across all files and repos.

For what it's worth, you'd need to use the same import path across all files and repos no matter what. It's just that right now that path has to include a .git.

Putting on hold for the broader enterprise story. For now my suggestion is to keep using .git in the paths.

Placed on hold.
— rsc for the proposal review group

GOVCS is currently a list of allowed vcs providers, maybe it can be overloaded to also mean the VCS provider to use?