Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/go: mod init: option to infer module name from git origin #60635

Closed
godcong opened this issue Jun 6, 2023 · 9 comments
Closed

Comments

@godcong
Copy link

godcong commented Jun 6, 2023

Currently, go mod init command initializes a new Go module in the current directory. However, it would be useful to have an option to initialize a Go module from a Git repository based on a configuration option in .git/config .

Add a new flag to go mod init command, e.g. --from=git , that allows initializing a Go module from a Git repository based on a configuration option in .git/config . This flag should accept the name of the config option as an argument (git,svn...) , and initialize the module using the repository's root directory as the module root.

Example usage:

go mod init --from=git

This command should read the Git URL from the remote.origin.url configuration option in .git/config , and initialize a new Go module in the root directory of the cloned repository.
Please let me know if you have any questions or feedback on this proposal.

@seankhliao seankhliao changed the title cmd/go: Add command to initialize Go module from Git repository based on .git/config configuration option proposal: cmd/go: mod init: option to infer module name from git origin Jun 6, 2023
@seankhliao seankhliao added the GoCommand cmd/go label Jun 6, 2023
@gopherbot gopherbot added this to the Proposal milestone Jun 6, 2023
@mvdan
Copy link
Member

mvdan commented Jun 6, 2023

This could be useful to people who are used to simply naming their public Go modules github.com/foo/bar. However, I see two minor disadvantages to doing this:

  1. Some VCS remotes/origins won't be valid Go module names. For example, many people use SSH to authenticate git pushes, like git@github.com:foo/bar.git.

  2. We shouldn't encourage users to tie the module name to the VCS URL. That might be a reasonable thing to do for personal or small projects, but for larger or more long-term modules, it's likely a better idea to decouple the name in case the VCS host changes, or the VCS repository/org needs to be renamed. This should be a conscious choice by the user.

@mvdan
Copy link
Member

mvdan commented Jun 6, 2023

I should also note that, if you run into this often enough, you can always create an alias or script with git remote get-url origin. You'll have to worry about the https:// prefix or any suffix like .git, but that's a problem one way or another.

@ianlancetaylor ianlancetaylor moved this to Incoming in Proposals Jun 6, 2023
@rsc
Copy link
Contributor

rsc commented Jun 14, 2023

We could have a special case for GitHub, but I'm reluctant to add more special cases for GitHub, and it still wouldn't be reliable: I git clone https://github.com/rsc/tmp but the right module path is rsc.io/tmp.

Also most of the time don't you run 'go mod init' before you push the first commit to GitHub?

@godcong
Copy link
Author

godcong commented Jun 15, 2023

@rsc
It's not a special case for github.
What I mean is to read the url from the .git configuration file and then execute init.
After all, most projects have the same module address as the project address.
Depending on the version management tool used, the project address is read from a different configuration.
It's just a few small steps, but it simplifies the process of starting a project with init. This is very useful for a large number of small projects. After all, the initialization of more projects may not know the name of what they are called.

@rsc
Copy link
Contributor

rsc commented Jun 21, 2023

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

@rsc rsc moved this from Incoming to Active in Proposals Jun 21, 2023
@hherman1
Copy link

hherman1 commented Jun 23, 2023

It seems easier to learn the normal mod init method than this special method that only works in certain, hard to predict cases. For this reason, I doubt that beginner materials will advise use of this feature. Then, who is the audience? Advanced users? I doubt advanced users would use this either, as they would probably prefer something they feel total control over. I’m not convinced this would be useful to many.

@rsc
Copy link
Contributor

rsc commented Jun 28, 2023

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

@rsc rsc moved this from Active to Likely Decline in Proposals Jun 28, 2023
@flimzy
Copy link
Contributor

flimzy commented Jun 29, 2023

It seems easier to learn the normal mod init method than this special method that only works in certain, hard to predict cases.

It seems that way, for those of us who have learned it. But StackOverflow and other newbie-centered places seem to prove this doesn't really match with reality.

I'm not weighing in in favor of this particular proposal, but I do think there's room for, at the very least, more explicit instruction from the go mod init tool, to help avoid newbie footgunning.

@rsc
Copy link
Contributor

rsc commented Jul 5, 2023

No change in consensus, so declined.
— rsc for the proposal review group

@rsc rsc moved this from Likely Decline to Declined in Proposals Jul 5, 2023
@rsc rsc closed this as completed Jul 5, 2023
@golang golang locked and limited conversation to collaborators Jul 4, 2024
@rsc rsc removed this from Proposals Jul 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants