I am using Circle CI to test my project. The project is a simple Go application consisting of a few packages and a main.go file. When referencing packages within my project I simply import them as "projectName/packageName" in the code. This works fine locally, however, when I push to git and it gets built on Circle CI I get the following errors.
package crypto-compare-go/handlers: unrecognized import path
"crypto-compare-go/handlers" (import path does not begin with
hostname)
I fixed this by prepending github.com/myGitUsername/projectName to my local package imports, this means that when I'm developing locally If I change one of the packages within my project, I have to push to git, then pull to be able to use them even though they are all under the same parent project folder. This seems like a slow, very inefficient process.
Has anyone had this problem with Circle CI before?
I fixed this by prepending github.com/myGitUsername/projectName to my local package imports, this means that when I'm developing locally If I change one of the packages within my project, I have to push to git, then pull to be able to use them even though they are all under the same parent project folder. This seems like a slow, very inefficient process.
Nope. You get this wrong. Your go will use the local $GOPATH/src/github.com/myGitUsername/projectName dir to compile. You access github.com only if you run go get -u <package path>. It is documented in How to Write Go Code.
Note that you don't need to publish your code to a remote repository
before you can build it. It's just a good habit to organize your code
as if you will publish it someday. In practice you can choose any
arbitrary path name, as long as it is unique to the standard library
and greater Go ecosystem.
Related
Relatively new to Go and wondering if there's any way to start a new project using a dependency you've already called go get or go mod tidy for in a previous project, without being connected to the internet?
Is there any way to import a whole package without having to reconnect to the internet to download/tidy further subpackages from the same dependency?
Reason I ask is that I don't normally have internet access where I code, so it becomes quite annoying to faff about to get things off the ground.
So far the only thing that seems to work is copying the old project and clearing it out, but that seems kind of ridiculous, even without having to specifically remove things you don't want to use again from the mod/sum files. Surely I'm missing something?
My $GOPATH points to ~/go
The package(s) I hope to use are in $GOPATH/pkg/mod. Would it be too egregious to place pkg/mod on the $GOPATH?
Thanks for any help you can give!
You can use vendoring. Run
go mod vendor
This will create a "vendor" directory and the go tool will use the dependencies from there.
See https://golang.org/ref/mod#go-mod-vendor fore more information.
I'm writing a MIDI parser that splits apart MIDI files and adjusts the volume on different tracks to allow for specific voice isolation to help practicing. I'm using a Go library, EasyMIDI. However, I ran into a use case that the library didn't cover, so I forked the repo and made changes that should fix my issues in the short term.
I'm able to successfully build when using my forked Github URL in my go.mod and import statements, but the code changes I made aren't being reflected. I added the function GetChannel() to an interface, and so should see it listed as an option. When I click into the source for another function that was originally implemented, I see that my VSCode is referencing the non-forked repo when grabbing the code (see screen snippet below).
As you can see on the left, there is no GetChannel() function. If I click on "algo!guy" and select "!try431", I do see the changes I made and pushed to my fork. How do I get my code to recognize that I want my forked repo so I can get access to these changes I've made?
Edit: Thought I might as well throw in the go.mod and go.sum files that are generated upon a go build.
go.mod
module github.com/Try431/acc-midi-splitter
go 1.12
require github.com/Try431/EasyMIDI v0.0.0-20190921213858-238fe2946087
go.sum
github.com/Try431/EasyMIDI v0.0.0-20190921213858-238fe2946087 h1:dXDwjgIHMgL4zow9ixgTslZ3cWZHHIu3+FurDjDC6wA=
github.com/Try431/EasyMIDI v0.0.0-20190921213858-238fe2946087/go.mod h1:c/dd/WkUR9yfzjC9sPO9J0vh5TzTmE8ryAvEviTDwgg=
github.com/algoGuy/EasyMIDI v0.0.0-20180322051653-708ca39e7399 h1:f0h3xTKQjrTzAUwqMJr1TY3lk3gTK8R4v7ZjcSMiwm8=
github.com/algoGuy/EasyMIDI v0.0.0-20180322051653-708ca39e7399/go.mod h1:z6svyEeOasADFxg4gn6funK2OBjocr62B4J7ZPodCPs=
I've tried deleting the algoGuy lines in the go.sum, but obviously the lines are put back on a go build.
You can use a replace statement in go.mod:
replace original => fork
This should make references to the original repo in the forked source lookup from the forked repo.
I've recently started using go and planned to use following directory structure for my code: src/mycompany.com/project (so package name would be mycompany.com/project/component), however during code review my coworker (who worked with go before) pointed out that it's a convention to place code in src/github.com/mycompany/project (so package name would be github.com/mycompany/project/component).
I can understand that this is convenient for personal projects, but it looks weird to me to have it for company projects. Why does it matter which source control website company is using? What if company will decide to move to bitbucket later on - should all projects be refactored to have package names starting with bitbucket.org?
It is definitely possible to not use github.com: kubernetes have package name starting with k8s.io/kubernetes, and go book has package names which start with gopl.io (and both use github).
Question is: are there any caveats if package name doesn't start with github.com? E.g. maybe dep won't work properly (go get seems to work fine) or something else?
Also: what is the right way to have package name mycompany.com/project and have source code hosted on github?
If you set up the web server at mycompany.com to host your Go packages, there's nothing at all wrong with that approach.
But if the only reason to do that is to have "vanity" package names, it's probably not worth it.
Put another way: Your package name must match its hosting location. If you're using GitHub to host your project at github.com/mycompany/foo then your package name is github.com/mycompany/foo--there's no choice in the matter.
If you want to host your software on GitHub but still use mycompany.com as the package name, then you could set up GitHub to host mycompany.com's web page using the GitHub pages feature. But if you're an established company, then you probably already have your site hosted elsewhere, and it's not an option to move hosting to GitHub. And even if you don't already have a company web site, there's practically no reason at all to do this for the sake of Go packages.
I am starting in Golang development. Right now my boss gave me the repository of a project that other developer made, now he's gone of the company and I am not able to ask him some things related to it. Right now I have a confussion about the project structure that he pushed to the repo, the structure is the next:
|-MyApp
|--bin
|--pkg
|--src
|----api (the code of the app)
|----github.com
|----golang.org
|----gopkg.in
To me, it's exaclty as the estructure of the Go, 1.- in the repo should not be only the api folder?
If I go to the api folder and make go run main.go I get a message that some packages are not found even when they are in the folder, 2.-how I specify the packages in the go run command?
3.- Is a good practice to set this kind of structure for the golang projects? I see in the code that he exported the packages only with "package1", if I copy and paste the code of the app inside the golang workspace then I have to specify the name of the folder to export the packages, example: "myApp/package1" so there I have that doubt. Thank you
That all depends. There is not a single right way for everything.
It seems as if this repo decided to vendor everything, the whole GOPATH. That is okay but with the "modern" vendor folder today one would do it probably differently.
Never do go run. That's for toy programs only. Build your software with go build and go install. These command work on package path.
For everything else: Please see the official documentation https://golang.org/doc/code.html and stick to it (which means you should move stuff around a bit).
I am trying to have a local copy of current code base of mgo.v2. https://gopkg.in/mgo.v2 says to install using go get gopkg.in/mgo.v2. I forked it from https://github.com/go-mgo/mgo/tree/v2 and trying to install it from go get forked repo from git but it changes the package structure(changes from /src/gopkg.in --> /src/github.com) and it fails saying
src/github.com/eateshk/mgo.v2/error.go:4: "ERROR: the correct import path is gopkg.in/mgo.v2 ... " evaluated but not used
I understand the error, but what's the solution for this ?
This is a common problem when forking go packages. Canonical or "vanity" imports require the code to live in the specified path or they won't compile. The only solution is to remove the // import "gopkg.in/whatever" comment that exists somewhere.
There are other problems with your approach as well. imports within their repository will resolve back to the original repo and cause all kinds of confusion unless you rewrite them.
Rather, I suggest an alternate approach. The only place this can live on disk without causing problems is $GOPATH/src/gopkg.in/mgo.v2. Anything else will cause problems. So:
go get gopkg.in/mgo.v2
cd $GOPATH/src/gopkg.in/mgo.v2
git remote add mine your_git_fork
Now you can pull upstream changes from origin and push your changes to mine. It feels a bit odd, but it really is the only way to work from a fork without causing tons of extra pain by rewriting things.