I am trying to implement the go mod dependency management for my project.
I have run command go mod init then go.mod file is created after that execute the go build command.
It give me following error.
gopkg.in/ahmetb/go-linq.v3: gopkg.in/ahmetb/go-linq.v3#v3.1.0: parsing go.mod:
module declares its path as: github.com/ahmetb/go-linq/v3
but was required as: gopkg.in/ahmetb/go-linq.v3
I don't know why this is happening and what to do
Don't use the gopkg based import.
Search your files for references of "gopkg.in/ahmetb/go-linq.v3" and replace with them "github.com/ahmetb/go-linq/v3"
Related
When I run go mod tidy, it breaks because a package imported by my project imports another package using path github.com/coreos/bbolt, but when it fetches the package from this path its go.mod says its path is go.etcd.io/bbolt.
The problem is that both the importing package and the imported package are 3rd party packages. I know I could edit the go module cache to fix it, but it would be a real hell fixing it when new versions of these packages become available.
Partial echoed messages are shown below:
github.com/coreos/etcd/client tested by
github.com/coreos/etcd/client.test imports
github.com/coreos/etcd/integration imports
github.com/coreos/etcd/etcdserver imports
github.com/coreos/etcd/mvcc/backend imports
github.com/coreos/bbolt: github.com/coreos/bbolt#v1.3.5: parsing go.mod:
module declares its path as: go.etcd.io/bbolt
but was required as: github.com/coreos/bbolt
So, how can I fix or work around this situation?
You can fix this solution by using the replace directive
Simply add:
replace github.com/coreos/bbolt v1.3.5 => go.etcd.io/bbolt v1.3.5
at the end of your go.mod file
The mismatched path implies that your dependency (github.com/coreos/etcd/mvcc/backend) is written against an old version of the bbolt repository — one that predates commit e65d4d.
I notice that the current go.mod file in the github.com/etcd-io/etcd repo specifies its module path as go.etcd.io/etcd/v3.
So the most robust fix for you is probably to update to that path, which you can do by changing your import statements to refer to the new canonical import path and running go mod tidy to update your dependencies accordingly:
sed -i s,github.com/coreos/etcd,go.etcd.io/etcd/v3,g $(find . -name '*.go')
go mod tidy
Barring that, you could explicitly choose a version of github.com/coreos/bbolt that matches the older import path. I notice that the highest version for that module listed at https://beta.pkg.go.dev/github.com/etcd-io/bbolt?tab=versions is v1.3.3, and v1.3.4 does seem to add a go.mod file with the updated path. So as a fallback, you could try:
go get -d github.com/coreos/bbolt#v1.3.3
The downside to that approach is that v1.3.3 is the end of the line: you wouldn't be able to pull in bug-fixes after that point, because those fixes are all at the go.etcd.io path.
You could also use the replace directive with the command line, as example:
go mod edit -replace github.com/pselle/bar=/Users/pselle/Projects/bar
More info in this article
I have a fork of someone's code. Their module name is formatted like so:
module github.com/foo/bar/v3
I've made some changes locally and have updated the local go.mod to be v4 instead of v3 but this now causes the running of the tests locally to fail (see below, I've genericized the output).
Note: the go.sum at this point is empty.
$ go test -v
go: finding module for package github.com/foo/bar/v3
go: found github.com/foo/bar/v3 in github.com/foo/bar/v3 v3.0.0
# github.com/foo/bar/v4_test [github.com/foo/bar/v4.test]
./some_test.go:232:19: x.Y undefined (type *package.Example has no field or method Y)
FAIL github.com/foo/bar/v4 [build failed]
I'm not sure why it's trying to locate the actual v3 version of the package, and thus updating the go.sum to include it?
I can see from the test file that this package uses a different package name (e.g. package foo_test) so it doesn't rely on the exported data structures to exist when writing their test code. So maybe that's why this happens? it sees the reference to x.Y and then goes to lookup x in github.
But then I'm not sure why the test would run fine when I was using the v3 reference in the go.mod file?
Any ideas on what's happening here and what the right process should be for bumping a go module when you're working on a forked project?
Thanks.
If you change your module name in go.mod file, you have to replace all your import path with the updated module name.
As you replaced your module github.com/foo/bar/v3 with github.com/foo/bar/v4, you must find and replace all your reference of github.com/foo/bar/v3 with github.com/foo/bar/v4 throughout the whole project.
Then your $ go test -v should run properly.
As a work requirement learning gRPC through an online course.
I have a project defined in folder greet (outside of GOPATH) with three packages called:
greet_client
greet_server
greetpb
In the go.mod file at the root of my project, I've specified the following:
module example.com/myuser/myproject
go 1.14
The code in greet_server/server.go makes a reference to greetpb.
I'm referencing it like the following:
I'm able to run server.go successfully.
It returns the expected the result:
My question is on the red squiggly lines VSCode throws saying it could not import greetpb:
Here's how package greetpb is defined (it's an auto generated file):
How can I get rid of this warning message?
Is it something I've not setup properly?
Update:
When I try to ctrl+click to view the module greetpb on the file server.go, I note that it's pointing to the url pkg.go.dev.
How can I make the program to do a "local" lookup?
Why would you use example.com? You don't have your package defined there.
Initialize go modules first i.e.
go mod init github.com/$USER/$REPO
Go mod vendor
go mod tidy && go mod vendor
That's it.
I am facing an weird issue where after vendorising my dependencies with go modules, go build command is overriding the main.go file with random data.
Start of the file looks like this:
����
H
H__PAGEZEROx__TEXTpxpx__text__TEXT��7�__rodata__TEXT��7Y��7__symbol_stub1__TEXT�V��V�__typelink__TEXT�V�(�V__itablink__TEXTP#V�
P#V__gosymtab__TEXT�JV�JV__gopclntab__TEXTKV
"KV�__DATApx�|px c
__nl_symbol_ptr__DATApx�pxs__noptrdata__DATA�sx���sx__data__DATA�&{���&{__bss__DATA �{��__noptrbss__DATA�}�2__DWARF�}�{�� __zdebug_abbrev__DWARF�}�{__zdebug_line__DWARF�}'W�{__zdebug_frame__DWARF;H���;8�__zdebug_pubname__DWARF�څ�K�ʃ__zdebug_pubtype__DWARF�&����__debug_gdb_scri__DWARF��6�ӄ__zdebug_info__DWARF���
�ӄ__zdebug_loc__DWARF䉑��y�__zdebug_ranges__DWARFU��ZE�H__LINKEDIT�}L���L��*�����,�r��� Pu,u,x,xo�� /usr/lib/dyld 8/usr/lib/libSystem.B.dylib h/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation `/System/Library/Frameworks/Security.framework/Versions/A/Security$
� Go build ID: "OLftMbjtv5aWMkI_0qrD/LhWRtD0wcaKFWRYSDOa9/7dFWcNOQ4BpWWqZQW07D/pkR9ABiz-SHIBaJIZ1ur"
����������UH��AWAVATSH���=|I��
Go version: go version go1.12.5 darwin/amd64
Enabled Go moduled with export GO111MODULE=on
Folder structure:
go.mod go.sum log.go main.go vendor
FYI: only main.go is being overwritten, not log.go.
Go module initialised with go mod init
App vendorised with go mod vendor
Not sure if I am doing something wrong. Any help is appreciated.
The module name should not be main.go as it is a file inside a package. Please use your project name for module name in go mod init.
For example, if your project root is hello, name your package hello, not main.go.
Also if you want to use the module over and over again, please consider using your repository name as the module name.
Go handles packages not individual files. Go modules are used to organize packages. Know more in official documentation
I'm trying to understand how to organize my golang project using go1.11 modules. I tried several options, but none of them worked.
I have some code in the main package under the application folder and a local package that the main package uses.
$GOPATH
+ src
+ application/
+ main/
+ main.go
+ otherFileUnderMainPackage.go
+ aLocalPackage/
+ someCode.go
+ someCode_test.go
+ someMoreCode.go
+ someMoreCode_test.go
Files in the main package, imports ../aLocalPackage. When I compile by go build main/*.go it's working.
Then, I ran go mod init application: V.0.9.9 and got the go.mod file, but the build always fails. I always get error about not finding the local package: build application:V0.9.9/main: cannot find module for path _/.../src/application/aLocalPackage. I also tried to place the local package right under src/, place it under main/ etc. but none of these methods worked for me.
What is the way to use modules and local packages?
Thanks.
Relative import paths are not supported in module mode. You will need to update your import statements to use a full (absolute) import path.
You should also choose a module name other than application. Your module path should generally begin with a URL prefix that you control — either your own domain name, or a unique path such as github.com/$USER/$REPO.
I had some problems working with local packages myself.
There are two tricks to make it work:
you run "go build" in the package directory
This compiles the package and places it in the build cache.
This link about code organisation in go explains more.
You can identify where the cache is using:
>go env GOCACHE
/home/<user>/.cache/go-build
Import using a path relative to the project
I puzzled loads over what the correct import path was and finally discovered that go doc or go list will tell you.
>go doc
package docs // import "tools/src/hello/docs"
>go list
tools/src/hello/docs
For example. I have a hello world API project and was using swaggo to generate documentation which it does in a docs sub-directory.
To use it I add an import:
_ "tools/src/hello/docs"
For my case the _ is important as docs is not used directly but we its init() function to be invoked.
Now in hello/main.go I can add "tools/src/hello/docs" and it will import the correct package.
The path is relative to the location of go.mod if you have one.
I have tools/ here as I have a go.mod declaring "modules tools".
Modules are a different kettle of fish - see https://github.com/golang/go/wiki/Modules.
Recent versions of go (1.11 and later) can create a go.mod file which you may use to fix the version of a module that is used and avoid go's crazy default behaviour of just downloading the latest version of any package you import.
I have written a blogpost on how to start your first Go project using modules.
https://marcofranssen.nl/start-on-your-first-golang-project/
In general it boils down to just create a new folder somewhere on your system (doesn't have to be in GOPATH).
mkdir my-project
cd my-project
go mod init github.com/you-user/my-project
This will create the go.mod file. Now you can simply create your project layout and start building whatever you like.
Maybe one of my other blogs can inspire you a bit more on how to do things.
https://marcofranssen.nl/categories/software-development/golang/