Golang hurdles (extra chars to keep topic edit happen)

Getting Help
1

This so pisses me off. Guess I spend the next four weeks figuring out how to get golang set up correctly. This seems to be the biggest hurdle in using Golang.

cadayton@Popsu:~/go/example/hello69$ go mod init
go: cannot determine module path for source directory /home/cadayton/go/example/hello69 (outside GOPATH, module path must be specified)

Yes very first thing I want to do is have packages on the F’ing internet.

Example usage:
‘go mod init example.com/m’ to initialize a v0 or v1 module
‘go mod init example.com/m/v2’ to initialize a v2 module

Run ‘go help mod init’ for more information.

1 Like
2

So the below worked. I had to manual create the directories and then execute the ‘go mod init’ command from that directory.

My expectation was that ‘go mod init’ would be smart enough to know read my $GOPATH and determine that directory didn’t exist and create it for me and then place the go.mod file there.

Guess I need to lower my expectations.

cadayton@Popsu:~/go/example/hello69$ go mod init example/hello69
go: creating new go.mod: module example/hello69
cadayton@Popsu:~/go/example/hello69$ ls
go.mod
cadayton@Popsu:~/go/example/hello69$ $GOPATH
bash: /home/cadayton/go: Is a directory

3

What does this mean? Are you trying to say that you are confused because the example usage includes a URL? You don’t have to use a URL. You can go mod init neverontheinternet if you want.

It would probably be more productive to read the manual / getting started guides. I’m not sure why you are expecting go mod init to read your $GOPATH and set and place a go.mod file there. Start here:

A module is a collection of Go packages stored in a file tree with a go.mod file at its root. The go.mod file defines the module’s module path, which is also the import path used for the root directory, and its dependency requirements, which are the other modules needed for a successful build. Each dependency requirement is written as a module path and a specific semantic version.

As of Go 1.11, the go command enables the use of modules when the current directory or any parent directory has a go.mod, provided the directory is outside $GOPATH/src. (Inside $GOPATH/src, for compatibility, the go command still runs in the old GOPATH mode, even if a go.mod is found. See the go command documentation for details.) Starting in Go 1.13, module mode will be the default for all development.

What are you trying to do? It’s 2023 so you should probably not worry about $GOPATH and instead use go modules unless you have a specific reason (like working on a very old project; nearly everything has migrated to go modules these days). Why are you even worried about your $GOPATH?

There are a lot of other helpful getting started guides here:

You might want to specifically check this out:

If you have a specific problem/question, I’m sure people here (or on r/golang or the gopher discord server) would be happy to help you out.

2 Likes
4

Thanks for the references.

Just ranting out of frustration, I should know better. I’ll RFM.

Thanks, Again

5

I basically have this in my fingers for every new quick project:

cd ~/work
mkdir newproj
cd newproj
go mod init mymymynickname/thenewproj
vi main.go

If you have only one source-file, this works:

go run main.go

For multiple files:

go run main.go file2.go

Or

go build
./thenewproj

When including new imports in your source-file (e.g. from GitHub):

go mod tidy
1 Like
6

For a simple case where the files are in one folder, as of go v1.11, you can use this to run multiple as well:

go run .

I use that pretty frequently for simple use cases where I’m building programs to do one-off tasks that are more like I’m using go as a scripting language.

1 Like
7

Thanks for the pointer (no pun intended), Dean

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.