proposal: infer module name via version control when running `go mod init`

[Jon Calhoun]

Hi everyone,

Posting this here to get some general feedback before consuming anyone's time with a proposal on Github.

The current behavior in the Go tooling is to infer the module name when running "go mod init" (without a name) inside of $GOPATH/src/github.com/username/repo. Here is an example:

$ cd $GOPATH/src/github.com/joncalhoun/demo

$ go mod init # This creates a go.mod file

# go.mod file generated
module github.com/joncalhoun/demo

go 1.16

I am proposing that the tooling be updated to also infer this from version control if present. Using git as an example:

# not in $GOPATH
$ git remote -v

origin g...@github.com:joncalhoun/demo.git (fetch)

origin g...@github.com:joncalhoun/demo.git (push)

go mod init # This creates a go.mod file derived from origin

# go.mod file generated
module github.com/joncalhoun/demo

go 1.16

There are probably some edge cases to consider, like multiple VCS being present. In any ambiguous case I propose we stick to the default behavior of an error message.

The need for this is pretty minor - it saves me a handful of keystrokes at best - so I understand if it doesn't seem worth the effort. It feels close enough to the current behavior to be a good addition, but I admittedly haven't explored how easy/hard it would be to implement. 

Best,

Jon

[Wojciech S. Czarnecki]

Dnia 2021-05-11, o godz. 11:14:24
Jon Calhoun <jonca...@gmail.com> napisał(a):

> it saves me a handful of keystrokes at best - so I understand if it doesn't seem
> worth the effort.

Right.

> It feels close enough to the current behavior to be a good addition

Gopath is retiring soon. Anyway, Someone needs to do many more keystrokes
to int repository anyway.

> , but I admittedly haven't explored how easy/hard it would be to implement.

Look at the list of currently supported VCSes to get a feel of the task.
For the starter: infer module name from a Fossil's checkout file (it is a sqlite db).

Hoe this helps

> Best,
> Jon

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

[Jon Calhoun]

After more thought, the proposal should be altered to only support git in the first pass. It would cover a majority of users, wouldn't affect the experience in other VCS, and would simplify the initial implementation.

Doing every VCS at once would require someone learning how every VCS defines the default remote repository (if it even does), and building off that. It would be better to do each individually and let someone familiar with each VCS take charge of that specific PR using existing VCS implementations as a pattern to follow.

[Bryan C. Mills]

go mod init should only infer a module path when it can be certain that path is correct.

For packages already stored in GOPATH/src, it knows the correct path with high confidence: the path relative to GOPATH/src is the path by which the packages in the module are imported when in GOPATH mode, so it is safe to assume the same path in module mode.

On the other hand, a module hosted at a particular VCS path can be served through an arbitrarily different path using go-import metadata, and it could also be a private fork intended for use only with a replace directive (or intended to temporarily host a change while an upstream PR is outstanding). So we cannot assume that the VCS path necessarily corresponds to the module path — it seems more robust to ask the user to supply the intended path explicitly.

[Jon Calhoun]

I suspect that the VCS path gives nearly the same level of confidence in practice. My personal experience shows that it is pretty rare for the two not to line up, and when it does the developer made a conscious decision to do so and knows to work around it.

I'm also not suggesting that we remove existing behavior. go mod init <your module name> is still valid so we don't lose robustness there.

[Jay Conrod]

The go command used to infer the module path from .git/config for github origins specifically. However, that was removed in 1.13, based on discussion in #27951. It wasn't a strong enough signal, and since it's important to get the module path right early on, it seemed better to require that the path be set explicitly when it can't be inferred from the location within $GOPATH/src.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7beb2ab6-940c-451c-bee6-45ccf73ad8edn%40googlegroups.com.

[Jon Calhoun]

Sounds like this functionality was removed intentionally and will be a no-go then. Thanks for sharing the link Jay!