Proposal Details

https://github.com/golang/mod/blob/master/module/module.go#L538

You're applying special processing rules during the parsing process for modules with a name starting with gopkg.in, and you don't give any options to control this behavior. Moreover, you don't describe these special processing rules anywhere. Do you even realize that these are just crazy approaches to development? Who even thought of hard-linking special processing rules to some domains? Why for gopkg.in such a status? What if I ask you to implement such strict rules for my domain? Or is it necessary to be an Indian from London who is near you?

Comment From: ALTree

gopkg.in came before the module system (it's much older!) and was quite widely used. When the modfetch code for the module system was written, a decision was made to special-case gopkg.in in order to provide a pleasant user experience to the many people depending on packages that used the gopgk.in service.

This commit explains it a little bit: https://github.com/golang/vgo/commit/84430ca

don't give any options to control this behavior

Why do you need an option to disable the gopkg.in special-casing? Is it bothering you? How?

Moreover, you don't describe these special processing rules anywhere.

I guess it could be documented, but to me it seems like an internal detail that just provides a nicer migration-path to the old gopkg.in users.

Why for gopkg.in such a status?

Because it existed (and was quite popular) before the module system was implemented; and smooth migration of its users was deemed important.

What if I ask you to implement such strict rules for my domain?

Probably not. A new domain should just play nice with the current module path requirements. gopkg.in has special treatment because it was created first.

Comment From: Jorropo

You can find documentation on how the rules work at https://gopkg.in/.

Comment From: ALTree

Wait, I was wrong: it is documented, here: https://go.dev/ref/mod

As a special case, modules paths starting with gopkg.in/ must always have a major version suffix, even at v0 and v1. The suffix must start with a dot rather than a slash (for example, gopkg.in/yaml.v2).

and also

For paths beginning with gopkg.in/, this requirement is replaced by a requirement that the path follow the gopkg.in service’s conventions.

I'm closing here since I don't think there's anything else to do.

Comment From: mwriter

Why do you need an option to disable the gopkg.in special-casing? Is it bothering you? How?

This prevents uniform processing. And the most interesting thing is that module names in local mod and work files can be any, can start with gopkg.in, but can be processed through local cache repositories, and again, the uniformity of processing breaks down.

Comment From: mwriter

There is no direct relation but I can't help but mention some other problems that have recently arisen https://rajendrasharma.me/blog/the-v1-mystery-go-modules-reject-path

Go modules have hard-coded validation rules, not just conventions

And if different problems have led different people to the same conclusions then the style of developing a golang parsing subsystem may be wrong.

Probably not. A new domain should just play nice with the current module path requirements.

It was my ironic ;)

I'm closing here since I don't think there's anything else to do.

You don't need to change anything but at least add options to the module mod so that we can control the behavior of the parser.

Comment From: ALTree

This prevents uniform processing.

That's unfortunate, but I think you'll have to work-around it in any code or scripting you're doing, because it's unlikely a flag will be added to change the cmd/go behaviour for this corner case. The general policy is for the Go tools to have as few flags as possible to keep their behaviour simple.

Comment From: mwriter

That's unfortunate, but I think you'll have to work-around it in any code or scripting you're doing, because it's unlikely a flag will be added to change the cmd/go behaviour for this corner case.

Won't go build work either if it comes across a module with a domain gopkg.in without a version? Is this the parsing model used for the entire toolchain? Then it's all the more strange to keep it that way.

The general policy is for the Go tools to have as few flags as possible to keep their behaviour simple.

Good joke :) When will you cancel the flags from go build? Of course, we can spend effort and create a workaround for anything. But don't we all want to improve and unify the code, not create a legacy that is difficult to maintain? Let's be honest. When it comes to direct orders from superiors, any changes are made, any backward compatibility breaks. Not to mention such a small thing to add a few new options. Golang probably has the best modular system among all languages (Rust also has a beautiful one but a different one). But it can be made even better if you allow it to be flexibly configured, and even more so if you allow it to be configured if there are implicit rules.