On 2/25/21 8:31 AM, Brian Candler wrote: > I suggest that newcomers are told to create an empty directory, create main.go > in that directory, and then use "go run ." (a literal dot), "go build .", "go > fmt ." etc. Of course, this means that if you have several programs you need > to > create separate directories for them - but that's the right thing to do. > Plus, > these days, you're soon going to need "go mod init myprog" anyway, which will > create a go.mod alongside it.
I have found that using replace was problematic wrt vscode gopls and possibly build messages. Apparently that should be improved however I believe users are using replace that likely do not actually want or need to. There seems to be more interest in improving that situation than the documentation bugs, especially the onboarding documentation. The onboarding documentation, in my mind, is far more important. The wiki seems to point back to the start coding in go documentation too. I have switched from replace (though I still have one in use currently) to having each project in a folder with a single go.mod at it's root. Within that folder you can have multiple packages without any other .mod files and you do not need to worry about module versioning. All the files in each folder will be treated as a separate build. You can just cd into each folder, run go build and as long as the package is main then all .go files under that directory will be built into one binary. If you have another folder in the root directory next to the go.mod and within that, the .go files are package lib. Then you can simply import it into all your 'main' packages using: 'import lib "example.com/modulename/libfoldername"' In fact in vscode with gopls, typing lib.functionname will automatically import it for you. This way you can use any version control that you want to import files into any project (folder/package within the module) and not worry about the go specific tools except perhaps for publishing. Even then, you may not need to, as your end result may be something else, such as an installer. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/cff3dcbe-6f7a-adc7-ccac-b514ed2eec66%40gmail.com.
