[joshklein]

Making sure I understand this: I’m some independent developer working in many languages. I like every project I work on to be inside ~/work/ within a subdir I name based on the project.

I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~/work/go/src/github.com/joshklein/project/cmd/hello_world.go, but now I can have ~/work/go_hello/src/main.go. Right?

I understand this isn’t the main point, but frankly it’s the thing I care the most about.

[llimllib]

> I used to be annoyed that I had to put every go project into a dir 7-8 layers below that e.g ~/work/go/src/github.com/joshklein/project/cmd/hello_world.go, but now I can have ~/work/go_hello/src/main.go. Right?

yes

[lsllc]

You can put your project in ~/work/my-go-project but then symlink it to ~/go/src/github.com/joshklien/my-go-project (assuming your $GOPATH is ~/go).

But yes, with modules you don't need to do this anymore.

go mod init github.com/joshklien/my-go-project

[hiimnate]

Not all go tools respect symlinks, since Rob Pike decided that symlinks should not be supported.

https://github.com/golang/go/issues/15507#issuecomment-24158...

[nsajko]

Relevant: https://news.ycombinator.com/item?id=3075522

[ihuman]

Where in your gopath are you supposed to put your source code if you never intend to upload it? All gopath tutorials I see say to put your github in the path like you did, and never say what to do if its not public.

[AgentME]

If your project isn't intended to be uploaded (or is, but isn't intended to be consumed by other go projects as a go module), then you can make the project name whatever you want as far as I know.

[ilovecaching]

I actually organize all my projects using the go way, there's nothing that stops you from coexisting Haskell in the Go tree. The advantage is that if you are working on something like the kernel, you can maintain separate branches easily.

That said, mod allows you to put your project anywhere but in the GOPATH, so the answer to your question is yes. The path is virtualized in the mod file.

[Waterluvian]

It awfully breaks when you run into multiple systems that want things done their way. Like Go and ROS workspaces.

[humblebee]

When I first started using go I also was a bit annoyed at the fact that I had to have everything in my gopath, particularly when I forked a repo as none of the paths would lead to my fork.

I've since started to also organize all of my code the gopath way and I just set $GOPATH to $HOME. When forking I just add a new remote and work out of the upstream repo, which seems saner now as it reduces object duplication.

I don't know if I will ever move away from organizing my node this way if I can help it.

> That said, mod allows you to put your project anywhere but in the GOPATH

I don't know if I've run into this yet, though the only project[0] I've used gomod with has a makefile so it might do something to handle it.

[0] https://github.com/ipfs/go-ipfs

[tracker1]

I just create aliases wrk-projname that cd to the deeper directory. I've been following the pattern with ~/src/repo/user|group/repo (or project/repo for vsts).

[sigzero]

That's how I understand it reading that page.

[sudhirj]

You can put any project anywhere you want.

[sudhirj]

Why is this inaccurate? Go modules allows you to put any Go project anywhere on your machine and have it work fine - what am I missing?