Where to place go.mod file - go

I have a repository structure as follows :-
xyz/src
1. abc
- p
- q
- r
2. def
- t
- u
- v
3. etc
- o
- m
- n
I have created a .mod file in src and run go build ./...
Except for local packages everything is fine. So if abc/p is being used in def then it throws the following exception :- cannot find module providing package abc/p. The idea behind keeping the .mod file in src package was to make sure the path is being found from where the mod file is located. Can anyone suggest where should the mod file ideally should be? also i tried placing it one directory above in xyz but still same issue as well as i created one for each sub directory. I am bit confused on this. Will I have to create separate repository for abc and etc. But considering gopath which earlier used to work for the same I think module should also be able to do the same. Any suggestions?

The most common and easiest approach is a single go.mod file in your repository, where that single go.mod file is placed in the root of your repository.
Russ Cox commented in #26664:
For all but power users, you probably want to adopt the usual convention that one repo = one module. It's important for long-term evolution of code storage options that a repo can contain multiple modules, but it's almost certainly not something you want to do by default.
The Modules wiki says:
For example, if you are creating a module for a repository
github.com/my/repo that will contain two packages with import paths
github.com/my/repo/foo and github.com/my/repo/bar, then the first
line in your go.mod file typically would declare your module path as
module github.com/my/repo, and the corresponding on-disk structure
could be:
repo/
├── go.mod <<<<< Note go.mod is located in repo root
├── bar
│   └── bar.go
└── foo
└── foo.go
In Go source code, packages are imported using the full path including
the module path. For example, if a module declared its identity in its
go.mod as module github.com/my/repo, a consumer could do:
import "example.com/my/repo/bar"
That imports package bar from the module github.com/my/repo.

I have a single go.mod in the root of my go application. I am using the following structure inspired by Kat Zien - How Do You Structure Your Go Apps
At the minute one of my applications looks like this
.
├── bin
├── cmd
│   ├── cli
│   └── server
│ └── main.go
├── pkg
│   ├── http
│   │   └── rest
| │ # app-specific directories excluded
│   └── storage
│   └── sqlite
All packages are imported via their full path, i.e. import "github.com/myusername/myapp/pkg/http/rest" otherwise it causes problems all over the place and this was the one change I had to make going from $GOPATH to go mod.
go mod then handles all the dependencies it discovers properly as far as I've discovered so far.

Related

golang unknown revision module/vX.Y.Z and importing package properly

I have a golang application structure like this:
.
├── calc
│   ├── go.mod
│   ├── main.go
│   └── Makefile
├── go.mod
├── LICENSE
├── num
│   ├── go.mod
│   └── num.go
└── README.md
Where calc is an "application" where I'm importing the num package to add 2 numbers.
calc/go.mod
go 1.15
require github.com/github_username/goapp/num v0.2.1
num/go.mod
module github.com/github_username/goapp/num/v0.2.1
go 1.15
go.mod
module github.com/github_username/goapp/v0.2.1
go 1.15
When in /calc, and I run go run main.go, I get the following:
go: github.com/github_username/goapp/num#v0.2.1: reading github.com/github_username/goapp/num/num/go.mod at revision num/v0.2.1: unknown revision num/v0.2.1
What am I doing wrong? The github repo has the annotated tags.
For further context, I'm mimicking a production setup where we have six different mini golang services in folders such as calc, calc2, etc. where each "calc" service has a go.mod file.
module github.com/github_username/goapp/num/v0.2.1
Is nonsense. The semver version tag "v0.2.1" does not belong into the module name.
(Note that for major versions > 1, e.g. 4.3.1, the major version becomes part of the name like in module github.com/user/proj/folder/v4).
And one more: There are no source code belonging to the root go.mod so this module makes no sense whatsoever.
You really should not make that many modules.
Are you working with private repositories?
if yes, then you need to configure OAuth authentication:
export GITHUB_TOKEN=MY_GITHUB_TOKEN
git config --global url."https://${GITHUB_TOKEN}:x-oauth-basic#github.com/".insteadOf "https://github.com/"
Now, if you don't have the necessity to use private repositories!
Turn your repositories to the public that will solve the problem too.

How to run sibling Go applications (modules) from the parent directory

I have multiple Go projects (and all of them are also Go modules) all in a folder. They are all HTTP servers and exchanging REST calls, thus, I need all of them up and running simultaneously.
So, for local testing purposes, I thought it would be reasonable to run all of them from the parent instead of moving all of the project root directories and running go run main.go in multiple terminals.
container_dir/
├── prj1/
│ ├── go.mod
│ ├── main.go
│ └── ...
├── prj2/
│ ├── go.mod
│ ├── main.go
│ └── ...
└── ...
Here are some some commands I have tried and the error messages for each time:
container_dir $ go run ./*/*.go
##ERROR: named files must all be in one directory; have ./prj1/ and ./prj2/
container_dir $ go run *.go
##ERROR: stat *.go: no such file or directory
container_dir $ go run ./prj1 ./prj2/
##ERROR: cannot find package "github.com/jackc/pgx/v4" in any of:
/usr/local/go/src/github.com/jackc/pgx/v4 (from $GOROOT)
/home/user/go/src/github.com/jackc/pgx/v4 (from $GOPATH)
cannot find package ...
So, I can give a final rephase for the question: How to run multiple go modules in sibling directories when they have some third party dependencies etc.?
P.S: As possible with Go modules suggest container_dir for my projects is in an arbitrary location and I expect no $GOPATH relevance.
Go version: 1.13.6
Don't use go run outside of tiny, playground-style tests
Source paths are a compile-time concern and are irrelevant at runtime - being in "sibling directories" doesn't mean anything when the program is running
go run runs a single program; just like building a program and running its executable binary (which is what go run does) runs a single program.
Looks like your go.mod stuff is having problems dude.
remember you can do replace inside it and reference your other application
module container_dir/prj2
go 1.13
require(
container_dir/prj1 v0.0.0
)
replace (
container_dir/prj1 => ../prj1
)
require is the path you import but it'll get switched to the relative path on build.

How to use 'Local' modules in 'GoLang' [duplicate]

This question already has answers here:
How to use a module that is outside of "GOPATH" in another module?
(2 answers)
Closed 4 years ago.
I'm building an application using a 'Micro Service' architecture.
This means that I have different applications.
The truth is that some logic is in a 'shared' library.
See the following directory structure:
ROOT/
├── Service 1/
│ ├── src
│ ├──── app.go
├── Service 2/
│ ├── src
│ ├──── app.go
└── Lib/
├── Lib 1
│ ├── src
│ ├──── app.go
Service 1, Service 2, and Lib 1, are all initialized with the go mod command.
For Service 1, this resulted in a go.mod file with the following contents.
module github.com/kevin-de-coninck/datalytics/services/serviceOne
For Service 2, this resulted in a go.mod file with the following contents.
module github.com/kevin-de-coninck/datalytics/services/serviceTwo
For Lib 1, this resulted in a go.mod file with the following contents.
module github.com/kevin-de-coninck/datalytics/lib/libOne
The import statements of Service 1 contains a reference to the Lib 1
import (
"github.com/kevin-de-coninck/datalytics/lib/libOne"
)
However, when I try to build the application, the following output is showed:
go: finding github.com/kevin-de-coninck/datalytics/lib/libOne latest
go: finding github.com/kevin-de-coninck/datalytics/lib latest
go: finding github.com/kevin-de-coninck/datalytics latest
build github.com/kevin-de-coninck/datalytics/services/serviceOne/src:
cannot find module for path github.com/kevin-de-coninck/datalytics/lib/libOne
How can I resolve this issue so that i can use my LibOne package without making it public or whithout copying it across all the services?
Kind regards
After some fiddling around, I have found my answer.
It seems that the 'go.mod' and 'go.sum' file(s) should be placed in the 'src' directory.
After doing that, the application can be build and executed.

Structuring a multi-executable Go project

I am trying to build a micro-services architecture project in Go. I am currently using Go 1.11 which supports modules, so I put my root directory in an arbitrary chosen directory, outside of GOPATH.
If I am getting the micro-services architecture concepts right, although my microservices need to be independent, they can share dependencies (and I don't see another way to do stuff, is it?)
Below is my directory structure:
.
├── go.mod
├── lambda
│   └── account_create
│   └── main.go
├── readme.md
└── types
├── account.go
├── location.go
├── order.go
├── pricing.go
├── product.go
└── types.go
Now the behavior I expected was to be able to run go build lambda/account_create and get an executable with that functionality so I can supply it to the respective AWS Lambda function.
However, when I run the command, I get:
can't load package: package lambda/account_create: unknown import path "lambda/account_create": cannot find module providing package lambda/account_create
Please explain me why this does not work and give me some advice on how a project like this should look.
Thank you very much!
Edit Here is my lambda/account_create/main.go file contents:
package account_create
import (
"fmt"
"roasted.ro/pkg/types"
)
func main() {
account := types.UserAccount{Name: "Victor"}
fmt.Printf("Welcome %s", account.Name)
}
To answer the latter part of your question (as the first half is more about preference), you need to do:
go build ./lambda/account_create
Notice the ./. go build takes in a package name or a path. If you don't prepend the path with a ./, it assumes you are giving it a package name.
Edit: the package has to be main if you want an executable. According to the docs, you always have to use package main for projects that build an executable:
Executable commands must always use package main.
Edit: I'll add some opinions on layout:
Consider which parts of your project are exported to other go projects. Meaning someone could import your package and expect to gain value and not have their code break when yours changes.
That should be either in a github.com/you/pkg/somepath package or just github.com/you/somepath.
Anything else (other than main packages) should be under a /internal package.
I typically make a /cmd/myexecurable1 /cmd/myexecurable2 and so forth for each executable.

Error with Go modules build using /cmd structure

I'm new to go modules, and am taking them for a spin in a new project which I'm trying to model after the structure described here
Here is an example of my directory structure:
.
├── cmd
│   └── app_name
│   └── main.go
├── go.mod
├── go.sum
├── internal
│   └── bot
│   └── bot.go
└── pkg
├── website_name
│   ├── client.go
│   ├── client.options.go
│   ├── server.go
│   └── server.options.go
└── lib
└── lib.go
Is this idiomatically correct? I know there's not a whole lot of consensus out there, but I'd like to follow best practices.
When I run go build I get 'unexpected module path "github.com/ragurney/app_name/cmd/app_name"', but when I run go build ./... it works. Why?
When I move main.go to the top level everything works as expected. Should I just not use the /cmd pattern with modules?
To answer your first question, its completely opinionated and whatever you like best that is also easy to understand for others you should go with (I think it's fine).
To answer your second question the reason go build ./... works as opposed to go build from the root directory is because ./... starts in the current directory (the root) and searches for all program entry-points and builds them. When you move main.go to the root directory, with this new information, go build working then makes sense, as its only looking in the current directory.
You can explicitly say go build ./cmd/app_name which would also work.
Your application structure works perfectly fine with modules, as I use something very similar to it (https://www.ardanlabs.com/blog/2017/02/package-oriented-design.html) and modules work very well for me.
from what i can tell there is nothing wrong with your project structure. What has worked for me is to run the go build/run command from the project root
eg.
go run github.com/username/project/cmd/somecommand
go build -o somebinary github.com/username/project/cmd/somecommand
I prefer to add the specific file to build, there are some projects with more than one executable
go build -o app ./cmd/server/main.go

Resources