I have a go project which consists of several packages. First, the main package located at $GOPATH/src/myproject/main.go, and then an auth package located at $GOPATH/src/myproject/auth/<filename>.go. The main package references the auth package with an import "myproject/auth". Local build goes fine.
Now I try to use this project build with Travis CI, especially to learn more about Travis. Apparently Travis expects import statements which don't start with a hostname to be available from beginning, since I get the error package myproject/auth: unrecognized import path "myproject/auth" (import path does not begin with hostname).
On my local machine this is no problem, since my local go knows about its available sources in $GOPATH, and so about the project's subpackage, too, and just includes the sources.
What are the expected steps to do to make Travis work with this import statement as well?
Why not to use full path in import? It does not lead to any problem, right?
It works just fine both local and with CI (hopefully)
Related
I am getting this error from go mod tidy when I am trying to update my dependancies. I am primarily developing a webhook service to use with cert-manager and I cannot figure out how to resolve this dependency isssue since the packages I am dependent on are created by other developers and I cannot control those "sub dependency".
This is my output:
go.opentelemetry.io/otel/semconv: module go.opentelemetry.io/otel#latest found (v1.9.0), but does not contain package go.opentelemetry.io/otel/semconv
I looked the package up here: https://pkg.go.dev/go.opentelemetry.io/otel/semconv
and the problem for me seems like that the package have been restructured like this:
go.opentelemetry.io/otel/semconv/v1.9.0
as a subdirectory instead of package version.
Is there a way I can manipulate the underlying dependancy of the packages that my service is depending on?
Please leave a comment if you need addictional information.
Take a look at the accepted solution's comments
You may want to use a local copy of the module where you can fix the issue and use it. Steps for that
Clone the module repository git clone https://github.com/open-telemetry/opentelemetry-go.git
If needed, checkout to a branch/tag git checkout branch_name
In the go.mod file of your module, add the following lines
replace (
go.opentelemetry.io => /path/where/cloned/opentelemetry-go
)
Now you should be able to modify code in the cloned opentelemetry-go repo and use it in your module
I unwrapped the project and from that project i did go get. Then I received the following errors.
C:\Users\Downloads\gochess-master>go install main.go
main.go:14:2: no required module provides package github.com/dchest/captcha: working directory is not part of a module
main.go:15:2: no required module provides package github.com/go-sql-driver/mysql: working directory is not part of a module
main.go:17:2: no required module provides package github.com/jonpchin/gochess/goforum: working directory is not part of a module
main.go:18:2: no required module provides package github.com/jonpchin/gochess/gostuff: working directory is not part of a module
main.go:20:2: no required module provides package golang.org/x/net/websocket: working directory is not part of a module
Then I went and tried doing go get each of the packages. I try doing the go install main.go and got same error.
then I tried including the repo inside $GOPATH/src/github.com/jonpchin/gochess and tried doing go get from there. I got the same errors.
github.com/jonpchin/gochess is a couple of years old and has not been updated to use go modules. I suspect you are using Go 1.16 under which "Module-aware mode is enabled by default, regardless of whether a go.mod file is present in the current working directory or a parent directory". There are a few ways to address this but given that there is a plan to "drop support for GOPATH mode in Go 1.17" the simplest approach might be to download the code and setup modules yourself. The following process works for me (well I get prompted for a mysql password):
git clone https://github.com/jonpchin/gochess
cd gochess
go mod init github.com/jonpchin/gochess
go get
go build
.\gochess.exe
I recently added a new package and directory to my Go project, and now when I try to build it, I get errors about a password error on Gitlab.
I am not importing a new remote package, I am simply adding a new directory underneath my already declared module path. For instance, my go.mod has gitlab.com/example/api and the package I added is gitlab.com/example/api/postgres.
I am not actually hosting on gitlab, I just needed something to name the project as I worked on it. Clearly it won't find it on gitlab, but it is available locally. Why is go-get trying to download a package/path that is available locally?
Why is it only happening for this new package, and not for all of the existing package under this path?
Golang 1.14
You have to add replace above the require block in your go.mod to work with local package. For example:
replace gitlab.com/example => /Users/abc/projects/gitlab.com/example
Ref: https://github.com/golang/go/wiki/Modules
I'm currently working something on AWS Cloudformation which using this repo https://github.com/awslabs/goformation. Because I did some customise so I made a fork https://github.com/vrealzhou/goformation.
Now in my other project (using go module) I'm trying to using go get github.com/vrealzhou/goformation#v2.3.1 and I've got this error:
go: github.com/vrealzhou/goformation#v0.0.0-20190513073615-ff3b65adb278: parsing go.mod: unexpected module path "github.com/awslabs/goformation"
go: error loading module requirements
Does anyone know the reason and how to solve this problem? Thanks
You can use replace in your go.mod to use a fork instead of the upstream version. That way, you can make whatever modifications you need to the code without having to update the module path or import paths.
To be specific, in this case, you can do the following in your go.mod (I tested this by forking the repo, making a small change, and confirming it showed up):
require github.com/awslabs/goformation v1.4.1
replace github.com/awslabs/goformation => github.com/vrealzhou/goformation master
The first time you build or test, master will be replaced by the latest pseudo-version for your fork to make sure you get repeatable builds. The replace requires a specific version for the replacement.
I've installed go as per the custom installation clause of the installation instructions, as I have installed to a user directory, in order to accommodate having multiple versions of go.
When I go get . from my go project's src directory, I get the error message type already mentioned above ―
unrecognized import path (import path does not begin with hostname)
Can you please explain, why does go look for a hostname and how that should possibly be avoided in a typical project?
As an aside, the problem was originally encountered by me in setting up the following specific project and hash, which the accepted answer still refers to.
go get downloads dependencies and packages by assuming that the import path (in the import statements in source code) identifies a URL where the package can be downloaded, e.g. github.com/habeanf/yap. It works so long as developers use imports correctly; unfortunately, the developer of the yap project did not.
Where they import yap/app, they should be importing github.com/habeanf/yap/app, etc. The only fix would be to clone the GitHub repo into $GOPATH/src/yap manually and then try to build it. You might want to open a GitHub issue on that project and request that they fix the import paths so it can be built like a normal Go project.
I had the same problem with setting up the same project on windows (note: updated project documentation is here).
Turns out GOPATH was set up for my username by GO installation while I updated the system environment GOPATH according to this description from the docs:
Set $GOPATH environment variable to your workspace: export
GOPATH=path/to/yapproj
Removing GOPATH for my username solved the problem and I managed to build the application.
I'm posting this to prevent others from spending too much time on this issue as I did.