golib | Golang packages used in frp and fft

Because in Go 1.17 the module graph has been changed to enable pruning and lazy loading. The second require block contains indirect dependencies.

https://golang.org/doc/go1.17#go-command

If a module specifies go 1.17 or higher, the module graph includes only the immediate dependencies of other go 1.17 modules, not their full transitive dependencies. [...]

[...] If a module specifies go 1.17 or higher in its go.mod file, its go.mod file now contains an explicit require directive for every module that provides a transitively-imported package. (In previous versions, the go.mod file typically only included explicit requirements for directly-imported packages.)

Because the number of explicit requirements may be substantially larger in an expanded Go 1.17 go.mod file, the newly-added requirements on indirect dependencies in a go 1.17 module are maintained in a separate require block from the block containing direct dependencies.

Note: the go.mod file that you posted in your question has //indirect dependencies in the first require block. I suspect, inferring from the quoted docs "newly-added" term, that this is because those //indirect dependencies were already listed there and go mod tidy doesn't rearrange them. If you:

• manually delete one of those
• and/or recreate the go.mod file with Go version set to 1.17 or higher
• and/or run go mod tidy -go=1.17

then it will properly separate direct and //indirect dependencies in the two blocks. At least this is what I see empirically in my projects. Still looking for a more explicit mention in the docs.

Unfortunately, Perforce is not one of the version control systems supported natively in the go command, so you may need to apply a bit of scripting or tooling in order to slot in the libraries from your Perforce repositories.

One option is to set up a module proxy to serve the dependencies from Perforce, and have your developers set the GOPROXY and GONOSUMDB environment variables so that they use that proxy instead of (or in addition to) the defaults (proxy.golang.org,direct).

Note that Go modules compute and store checksums for dependencies, so if you have modified any third-party dependencies it is important that any modifications be served with unique version strings (or different module paths!) so that they don't collide with upstream versions with different contents. (I seem to recall that the Athens proxy has support for filtering and/or injecting modules, although I'm not very familiar with its capabilities or configuration.)

I'm not aware of any Go module proxy implementations that support Perforce today, but you might double-check https://pkg.go.dev/search?q=%22module+proxy%22 to be sure; at the very least, there are a number of implementations listed there that you could use as a reference. The protocol is intentionally very simple, so implementing it hopefully wouldn't be a huge amount of work.

Another option — probably less work in the short term but more in the long term — is to use replace directives in each module to replace the source code for each Perforce-hosted dependency with the corresponding filesystem path. You could probably write a small script to automate that process; the go mod edit command is intended to support that kind of scripting.

Replacement modules are required to have go.mod files (to reduce confusion due to typos), so if you opt for this approach you may need to run go mod init in one or more of your Perforce directories to create them.

With either of the above approaches, it is probably simplest to start with as few modules as possible in your first-party repository: ideally just one at the root of your package tree. You can run go mod init there, then set up your replace directives and/or local proxy, then run go mod tidy to fill in the dependency graph.

I am guessing the error message comes from https://github.com/golang/go/blob/release-branch.go1.16/src/cmd/go/internal/modload/init.go#L207-L210

In the last line of your ~/.bashrc, you meant export GOPATH=$GOPATH:..., not export GOPATH=$gopath:.... Since $gopath is not set, your GOPATH would end up being :/home/santiagoquinteros/code. The above code doesn't like it.

As others said, you don't need to set GOROOT. With go1.16, the module mode is the default, so you probably don't need to set GOPATH but live with the default GOPATH which is $HOME/go.

Many things have changed recently. I recommend newer sets of materials like https://golang.org/doc/#getting-started, https://learn.go.dev, https://play-with-go.dev/ , ...

Since go@1.13 to have a behavior similar to previous versions, you need to set GOPRIVATE environmental variable for private repositories

You must have protoc and the plugin (protoc-gen-micro) installed.

I think you omitted the second step.

See:

https://github.com/micro/protoc-gen-micro

And perhaps:

You can check permission of the service account using below command: