I have a go.mod file that looks like this:
module someName
go 1.13
require (
.
.
golang.org/x/crypto v0.0.0-20190621222207-cc06ce4a13d4
localpackage v0.0.0
)
replace localpackage => ../localpackage
This works just as expected! What I can't figure out is how can I add a certain version or commit hash to the replace directive!
For example:
replace localpackage => ../localpackage v1.0.0
or
replace localpackage => ../localpackage v0.0.0-20190731182444-35453ccff3d6
Doing this results in an error:
replacement module directory path "../localpackage" cannot have version
The error is quite clear that I shouldn't add a version to a local replace. I checked the wiki but I couldn't find an answer!
The question:
Is it possible to add this kind of replacement and how? What am I missing here?
As the error says: you cannot specify a version when the replace directive is pointed at a local folder. There is no guarantee and it is not a requirement that the replacement folder contains files of a versioning system, it is perfectly valid to just have "snaphots" of the Go sources. So in many cases it would have no meaning to specify a version.
However, if your local folder is a clone of a git repository for example, you may simply switch that to your intended version. E.g. execute a git checkout v1.0.0 in that local folder to switch to that version, and that version will be used.
Related
I wrote a program and want to encapsulate some logic.
So I did new module and pull it in my git. Link for git looks like
gitlab.xxx.ru/group/subgroup/proj
but when I tried to get it with go get, I got error
fatal: «https://xxx.ru:#gitlab.xxx.ru/group/subgroup.git/» unreachable: URL using bad/illegal format or missing URL
Go tried to load subgroup instead project.
I made folder gitlab.xxx.ru/group/subgroup/ in $GOPATH/src/ and clone my project.
And now it wrote
could not import gitlab.xxx.ru/group/subgroup/proj (no required module provides package "gitlab.xxx.ru/group/subgroup/proj")
So, if I understand correctly, in Golang 1.16 I can't just put my project in the correct directory and I can't use local packages.
How to fix loading from my GitLab and load it with ssh?
Thank you.
UDP go.mod in my proj.
module gitlab.xxx.ru/group/subgroup/proj
go 1.16
require (
golang.org/x/sys v0.0.0-20210608053332-aa57babbf139
golang.org/x/text v0.3.6
)
You may be hitting the intended behaviour from Gitlab which will prevent go from fetching the list of subgroups while trying to compute project dependencies. Since go get requests are unauthenticated, existing projects not under the root group are invisible and cannot be found.
To overcome this limitation, which Gitlab has yet to provide a solution, you can use one of the following two approaches:
Have the project located at the root and not in a subgroup (not always possible)
Leverage the .git extension as well as the replace directive in the project which imports your module (see below)
Go is able to fetch the project living under a subgroup if it knows the version control qualifier (.git). To indicate this, make sure you import the project using the following format gitlab.xxx.ru/group/subgroup/proj.git
While this alone works, it would force you to have all those .git in your imports. To overcome this, you also need a replace directive in your go.mod so you can use the original import path.
In the end, the project which imports your module should have a go.mod that look like this:
require(
gitlab.xxx.ru/group/subgroup/proj v1.7.0
)
replace(
gitlab.xxx.ru/group/subgroup/proj => gitlab.xxx.ru/group/subgroup/proj.git v1.7.0
)
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
The background:
Two Applications - A and B
Application 'A' contains two go.mod files
A/pkg/test/go.mod: (I keep here application specific structures which are gonna be reused by another services willing to integrate)
module A/pkg/test
go 1.14
require (
some_dependencies vx.x.x
)
A/go.mod: (root module importing pkg/test as local module)
module A
go 1.14
require (
A/pkg/test v0.0.0
)
replace A/pkg/test => ./pkg/test/
Now Application 'B' would like to re-use Application's A pkg/test package by simply importing it
The Adventage:
This solution lets any integrating services pull only dependencies of pkg/test module instead of importing whole application A tree
Current Solution:
Application 'B' imports pkg/test module of Application 'A' using following go.mod:
module B
go 1.14
require(
some_dependencies vx.x.x
A/pkg/test v0.0.0
)
replace A/pkg/test => gitlab.com/A/pkg/test v0.0.0-02345798575346-72cs44671e34
Now I really do not like using commit-timestamp_commit-sha approach here.
The problem:
I would like to use TAGS in order to import A/pkg/test module.
Repository A has a tag, say v2.0.0, created. When I replace v0.0.0-02345798575346-72cs44671e34 with v2.0.0, after running go mod tidy/download I am getting following error output:
reading gitlab.com/A/pkg/test/pkg/test/go.mod at revision pkg/test/v2.0.0: unknown revision pkg/test/v2.0.0
The question:
I assume bad package naming/module naming/tagging etc. might lead to such error. The question is what am I missing here in order to make it clear and work?
To take a nested go-modules package within a git repo, just add a tag to the directory that contains the go.mod file - and then append your version.
So in your case, the directory is A/pkg/test and lets say you wanted to use semver v0.0.1 you tag like so:
git tag -a "A/pkg/test/v0.0.1" -m "initial test checkin"
git push origin --tags # push all local tags
# git push origin "A/pkg/test/v0.0.1" # push a single tag
Please Note: from the Go wiki Should I have multiple modules in a single repository? - Russ Cox (the creator of vgo i.e. today's go-modules) warns:
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.
I'm using the Go thrift package from Apache, which is at lib/go/thrift in the Git repo at git.apache.org/thrift.git. This is the import statement:
import "git.apache.org/thrift.git/lib/go/thrift"
This works fine for using the official Apache code but we needed to make a change to the Apache code so I just added a replace directive to the go.mod file for the project to pick up our changed version of the package:
replace git.apache.org/thrift.git/lib/go/thrift => <local_path>/lib/go/thrift
where <local_path> is where the (patched) git repo was saved. I added a go.mod file to this location (<local_path>/lib/go/thrift) simply containing this:
module git.apache.org/thrift.git/lib/go/thrift
go 1.12
However the Go compiler ($ go build) insists on downloading and using the Apache package and is ignoring the replace directive. Any ideas on the cause of this problem?
The fix I found (after much experimenting) is to remove the go.mod file from <local_path>/lib/go/thrift (this step was essential) and add this go.mod file to <local_path>:
module git.apache.org/thrift.git
go 1.12
Plus also change the replace directive to remove the lib/go/thrift part like this:
replace git.apache.org/thrift.git => <local_path>
The import statement was unchanged.
Using go modules, I would like to replace labix.org/v2/mgo with github.com/globalsign/mgo. The http://labix.org/mgo repository is unmaintained and has been forked to https://github.com/globalsign/mgo
my code is stored outside $GOPATH in the directory ~/git/foo
I'm using go1.11
other go modules are working (for example go list -m all lists other modules, the files go.mod and go.sum are updating automatically. See the full file below)
I've tried the following in the go.mod file:
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
Running go build gives the following error:
build github.com/foo/bar: cannot find module for path labix.org/v2/mgo
The documentation in go help modules discusses Pseudo-Versions eg v0.0.0-yyy.., which I'm trying to use because the tags on https://github.com/globalsign/mgo are of the form r2018.06.15 and not v1.2.3 (semantic versioning).
In addition go help modules says:
Pseudo-versions never need to be typed by hand: the go command will accept
the plain commit hash and translate it into a pseudo-version (or a tagged
version if available) automatically. This conversion is an example of a
module query.
However I can't work out the command for generating a pseudo-version when I'm in the cloned github.com/globalsign/mgo (located at $GOPATH/src/github.com/globalsign/mgo). Hence the pseudo-version I've manually generated may be wrong.
The full go.mod file looks like:
module github.com/foo/bar
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
require (
github.com/DATA-DOG/godog v0.7.8
github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
github.com/alecthomas/colour v0.0.0-20160524082231-60882d9e2721 // indirect
github.com/alecthomas/repr v0.0.0-20181024024818-d37bc2a10ba1 // indirect
...
)
Try the go edit -replace command, without modifying the line of the original package.
This way you don't need to know the exact pseudo version beforehand, just the commit hash id.
So in your case, don't manually modify go.mod require section of "labix.org/v2/mgo", and run this command to append your commit "eeefdec" of your fork, on top of labix version:
$ GO111MODULE="on" go mod edit -replace=labix.org/v2/mgo=github.com/globalsign/mgo#eeefdec
After the first time you build or test your module, GO will try to pull the new commit, and then will generate the "replace" line with the correct pseudo version for you. So then you'll see on the bottom of go.mod:
replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015135952-eeefdecb41b8
When using the replace directive, leave the pseudo-version out.
It's also stated here, which points to an open issue.
Probably off-topic, but I've mostly used replace when I wanted to use a local version of some dependency. Why not import the forked lib which you'd like to use (instead of the original non-maintained one) and have mod resolve it properly?
The source being replaced (in this case labix.org/v2/mgo) also needs to be added to the require list with a version of v0.0.0 (even though it won't be downloaded). In the replace the source doesn't need a version but the target does.
However I haven't worked out how to auto-generate the pseudo version for the target (github.com/globalsign/mgo in this case), so I still needed to manually generate it.
Here's a better go.mod file:
1 module foo.bar/qux
2
3 replace labix.org/v2/mgo => github.com/globalsign/mgo v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df
4
5 require (
6 github.com/DATA-DOG/godog v0.7.8
7 github.com/alecthomas/assert v0.0.0-20170929043011-405dbfeb8e38 // indirect
<snip>
21 golang.org/x/image v0.0.0-20181116024801-cd38e8056d9b // indirect
22 labix.org/v2/mgo v0.0.0
23 )
Notice the require of labix.org on line 22; go mod tidy accepts this.
However I now come up against a different issue, the use of internal packages (referred to in issues like this: https://github.com/golang/go/issues/23970). I still haven't solved this new problem.
% go build main.go
/home/sonia/go/pkg/mod/github.com/globalsign/mgo#v0.0.0-20181015145952-eeefdecb41b842af6dc652aaea4026e8403e62df/auth.go:38:2:
use of internal package github.com/globalsign/mgo/internal/scram not allowed