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
)
Related
I've used openapi-generator to generate multiple SDK separately and put it in the same parent dir:
sdks
--- bar-api
------ go.mod
--- foo-api
------ go.mod
I'd like to be able to import bar-api in my client code. Initially there's bar-api's go.mod was generated as:
module github.com/coolrepo/bar-api
go 1.13
but I couldn't fix the imports in my client code:
bar "github.com/cool-repo/bar-api"
so what I did was:
sdks
--- bar-api
------ go.mod
---go.mod
i.e., created sdks/go.mod:
module github.com/coolrepo
go 1.13
and manually edited bar-api's go.mod to:
module github.com/coolrepo/bar-api
require (
...
)
replace github.com/coolrepo => ./..
go 1.15
Is there a better way to fix it? This one seems to work but looks kinda hacky with this replace.
The “better way to fix it” is to put all of the generated Go packages inside a single module, instead of splitting up the repo into multiple modules.
rm bar-api/go.mod
go mod tidy
You only really need to split a repo into separate modules if you need to be able to tag a release for one set of packages independently from another set of packages in the same repo. For generated service APIs, that probably isn't worth the development overhead of juggling versions for multiple modules.
I have my projects that have many packages which import each other and import outside packages. When I make a change to one of my low lever packages, and then push it to git it is fine and works in that section. When I go get it for use in another project that was working perfectly I now get this go get this error:
module declares its path as: github.com/xdg-go/scram
but was required as: github.com/xdg/scram
None of my code uses either of those directly. It looks like it automatically updated some lower external packages and broke things the used to then old import.
How do I either find out the package that is importing the wrong name or stop all auto-updates?
The go.mod file at github.com/xdg/scram declares itself as github.com/xdg-go/scram:
module github.com/xdg-go/scram
go 1.11
require (
github.com/xdg-go/stringprep v1.0.2
golang.org/x/crypto v0.0.0-20210322153248-0c34fe9e7dc2
)
The go.mod file should be updated to reflect the correct import path.
Unfortunately if this module is for you an indirect dependency, the best fix possible is to update whatever project you import that is directly importing it.
When that is not an option, a solution to this error is to clone the problematic repository locally and use the replace directive in your go.mod file:
module mymodule
replace github.com/xdg/stringprep => ../strprep
go 1.16.2
require (
github.com/divjotarora/mgo v0.0.0-20190308170442-1d451d2a3149
)
where ../strprep is where the code of the required module exists in your local machine, relative to the go.mod file of your project.
The downside of this of course is that you have to replicate this palliative fix wherever you plan to go get your modules.
Note also:
divjotarora/mgo is just a random example of a project that imports one of those packages using their old import path.
I'm using xdg/stringprep as an example because I can't find modules that import xdg/scram instead, but apparently it suffers from the same issue
Beside, you can use:
go mod why <package> to find out why a certain package is listed as a dependency of your project
go mod graph to show the full dependency graph. The output is in <package> <requirement> format
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 am trying to convert https://github.com/appscode/voyager from glide to go mod.
I am getting an error like below:
go: github.com/Sirupsen/logrus#v1.4.1: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"
go: error loading module requirements
How do I find out the source of this old Sirupsen module?
How do I find out the source of this old Sirupsen module?
Use the Go 1.13 beta (go get golang.org/dl/go1.13beta1 && go1.13beta1 download) or even better, try the latest Go on tip / master (go get golang.org/dl/gotip && gotip download).
Go 1.13 has improved error messages in general. It should help in your case, including most likely showing the import chain leading up to the error.
For example:
$ gotip build .
go: example.com/temp/mod imports
github.com/docker/libcompose/docker imports
github.com/Sirupsen/logrus: github.com/Sirupsen/logrus#v1.4.2: parsing go.mod:
module declares its path as: github.com/Sirupsen/logrus
but was required as: github.com/sirupsen/logrus
In that example, you can see that docker/libcompose/docker is importing the old and now incorrect uppercase version of Sirupsen/logrus.
The most common reason people see a Sirupsen/logrus vs. sirupsen/logrus case mismatch is when importing github.com/docker/docker or one of the other docker repos. Importing docker repos is a bit confusing with modules, including because:
The docker/docker repo does not follow semver.
There is a very old v1.13.1 semver tag on the docker/docker repo.
Even though it is a couple years old, it is still the "latest" semver tag on that repo, and hence that old version is picked by default by the go command if you don't ask for a more specific version.
That old docker/docker version imports the old and not incorrect uppercase Sirupsen/logrus, which can then trigger the error reported in the question above.
The docker client package has had breaking changes after v1.13.1.
There is generally confusion about docker/docker vs. docker/engine repositories, and about what import paths to use.
The docker repos do not have go.mod files.
For the docker/docker repo, the import path remains github.com/docker/docker, but it needs to come from github.com/docker/engine, so the recommended approach is often for a docker importer to do import "github.com/docker/docker" and edit their go.mod to something like this:
require (
github.com/docker/docker v1.13.1
)
replace github.com/docker/docker => github.com/docker/engine <tag-or-commit-hash>
Docker issue #39302 tracks trying to document how to import docker repos when using modules.
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/