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: Add a go new command to alleviate new user confusion #16383

Open
Abextm opened this Issue Jul 15, 2016 · 9 comments

Comments

Projects
None yet
8 participants
@Abextm

Abextm commented Jul 15, 2016

As #12488 mentions new users often have trouble understanding what the GOPATH environment variable is for, how to set it up, and how to use it.

To alleviate confusion I suggest we add a go new command. It would create a new project and serve as a introduction to new users. On first run it may look like:

~ $ go new
Enter a project name. This typically looks like: github.com/user/project
> user/entered/name
You do not seem to have a $GOPATH set. This is required for go to manage dependencies.
$GOPATH location [/home/username/go]:
> 
~/go/src/user/entered/name $

The tool would then create the $GOPATH structure, and add it to wherever you add $GOPATH on your os. It might also copy the default go playground example, or similar, to the new project directory and cd there. It could also, optionally, add $GOPATH/bin to your $PATH, or at least give guidance on how go install works.

Subsequent runs could just be:

~ $ go new user/entered/name2
~/go/src/user/entered/name $ 

or 

~ $ go new
Enter a project name. This typically looks like: github.com/user/project
> user/entered/name2
~/go/src/user/entered/name $

I think this would help new users understand the gopath structure hands-on, and get them writing code as opposed to dealing with environment variables.

@dr2chase

This comment has been minimized.

Contributor

dr2chase commented Jul 15, 2016

What does a new user do if they do not have a github account?
I'd suggest

$ go new
Do you have a github account [y for yes, n for no, default no]?
no
There is no 'go' subdirectory of your home directory.
Would you like to create that to contain all your Go work? [y for yes, no for no, default yes]?
yes
Would you like to create a standard set of tutorial examples [y for yes, n for no, default yes]?
yes
Would you like to set the standard Go environment variables (GOROOT, GOPATH) [Y/n]?
yes
Would you like to add $HOME/go/bin to your PATH [Y/n]?
yes
...

or something along those lines. Maybe if you run Go without a GOPATH (or an inferrable GOPATH) it just suggests all the defaults in one go. Look in the home directory for .git* and .hg*, and work from there.

@mem

This comment has been minimized.

mem commented Jul 15, 2016

This is a nice idea to help people familiarize with the project, but it goes so far out of what the go program should be doing that I don't see a reasonable way to make it a subcommand.

Also, this might sound like nitpicking, but I mention it to illustrate the issues with the approach: in your example you show the current working directory changing from $HOME to some other location. A program (go) cannot do that. You'd need to make this a shell alias to work it like that, and this strongly points in the direction of an external tool, not something baked into the go program. In the original issue I provided an example of such an external program, that by way of some nasty tricks disguises itself a the go program. And even that implementation is not capable of doing what you show here.

@Abextm

This comment has been minimized.

Abextm commented Jul 15, 2016

@dr2chase Should probably make it more clear the url just is a namespace, but typically is some version control service, like github or bitbucket. If we wanted to sniff git username, that may be difficult for those of us who do not use github because while git config --list --show-origin shows my username, it does not show the host I use most.

@mem On windows we could use a wrapper batch script and call the command gonew and the user wouldn't see the difference in 99% of cases if we do it right. In *nix we would have a sh script that would have to be ran . gonew which is unfortunate, but the standard way. I think we would also need this to set the env vars anyway, but I'm not sure.

Additionally I do agree it is somewhat out of scope for the go command but I would always prefer not cluttering PATHs with 28 different executable for every tool, however we may have to add there if we want cd functionality.

@dr2chase

This comment has been minimized.

Contributor

dr2chase commented Jul 15, 2016

I think we have different ideas of "new" user. I imagine people who would give you a blank look if you said "git" or "namespace". It's hard for me to imagine someone adequately competent at Git (i.e., more competent than I am) who would have difficulty getting started with Go.

@Abextm

This comment has been minimized.

Abextm commented Jul 15, 2016

@quentinmit quentinmit added this to the Proposal milestone Jul 29, 2016

@bradfitz

This comment has been minimized.

Member

bradfitz commented Sep 12, 2016

@adg, thoughts on this? It's similar to your "workspace" idea.

@adg

This comment has been minimized.

Contributor

adg commented Sep 16, 2016

It is indeed similar to my go workbench idea.

@adg adg removed their assignment Oct 24, 2016

@adg

This comment has been minimized.

Contributor

adg commented Oct 24, 2016

I think #17262 will probably make this less important. But it's a significant problem to solve, and there are many ways of looking at it.

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 14, 2016

  1. There's a lot of room for helping users here. It's not clear that this is the right amount, nor that the right amount belongs squarely in the go command versus something else.
  2. We don't know yet how much is left after we ship GOPATH=$HOME/go by default.
  3. Ideally anything added to the go command would be helpful even once you become an experienced user, something power users would still reach for too. "go bug" is a good example: it helps new users but it's still useful once you know enough not to strictly need it. It's unclear this "go new" stays useful.

So it seems too early and maybe too much or too little. I think we need more information to make this more concrete.

Possible paths forward:

  • Start a discussion on a mailing list like golang-nuts@ instead.
  • Write a more concrete proposal of exactly what you want "go new" to do.

@rsc rsc added the Proposal-Hold label Nov 14, 2016

@gopherbot gopherbot added the Proposal label Mar 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment