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).
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.
A little backstory:
I am creating my first Go web app for school. The professor said that I could use Go. I asked him if I could use the latest version, 1.13, rather than the version installed on the server, 1.10, to leverage the module management feature and the updated errors module. He did not say that I was restricted to 1.10 and even gave me the contact information of the server admin. I reached out to the server admin with my professor CC'd and he said he doesn't want to update the server's version of Go in the middle of the semester. He then included instructions on how to download, install, and use whatever version of Go that I need in my home directory.
Pick your version:
https://golang.org/dl/
Set it up for your own use:
https://golang.org/doc/install
I installed go 1.13 and updated my own envvars to reflect this version and everything works.
Well, the other requirement is that I have to hand my professor my project and that it has to compile on the server. I am thinking that if I hand him a bundle and give him directions on how to build it, then I've technically met the requirements of the project so far.
My question is, does Go have anything that takes my Go v1.13 environment and packages everything up so that the project can compile on the target server? I have only been able to find solutions along the lines of "just copy the project binary to your production server" but that doesn't help me. I need it to compile on the production server. Besides, I tried copying my binary to the production server and it couldn't find my html templates (stored in ./ui/html/ directory) but I guess that will be solved in this discussion or saved for another SO question later.
student#universityserver:~$ ./web
INFO 2019/09/22 10:21:52 Starting server on :5089
INFO 2019/09/22 10:23:03 <ipaddress>:63527 - HTTP/1.1 GET /
ERROR 2019/09/22 10:23:03 handlers.go:29: open ./ui/html/home.page.tmpl: no such file or directory
The only thing I can think of right now is to basically add everything they need (the go amd64 binary distribution and all modules) and write a script that handles it all (extract go in local folder, export envvars, build, etc.)
Dear, Professor.
Copy this tarball to your home directory, extract, run build_my_goapp.sh script.
Sincerely,
Your student
The answer in my case was that I can supply a Makefile that does anything I need it to do.
(It's actually good practice, if not an expectation, of a project that is turned in.)
The requirements were that my project needs to compile on the server and that I had to supply a Makefile. Therefore, any downloading, installing, and setting up of a Go environment for my project can be done, as long as everything happens in the user's environment and is not something that needs sudo to install correctly. The server does not have Docker.
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 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.
I've decided to use Eclipse (with the goClipse plugin) as my editor for go projects.
I already had go installed and (before choosing Eclipse) I had designated c:\go-workspace as my workspace.
I now want to configure Eclipse to use that workspace as my location for go work.
I plan to import various projects from github and create my own github account where I can commit changes, etc. All those imports will be under the src/directory, and this is in accordance with this article that seems to indicate it is best to have one go workspace with everything under the src/ directory: https://talks.golang.org/2014/organizeio.slide#9.
I'm having issues creating a go project in Eclipse.
I choose File > New Go Project and browse to c:\go-workspace.
I enter a project name in the dialog but I get a message saying that a directory already exists at the specified location and my only choice is to cancel.
I then tried creating a new Eclipse workspace but when Eclipse was finished it indicated it is a Java project.
How do I accomplish what I want to do? Or perhaps the "best practice" for what I want to do is something else.
Ok, you already decided to go for IntelliJ but maybe someone else might be interested in an answer though ...
I also had some fights with GoClipse but finally I got it working. The solution is to input the whole path (including the project name). So for example your GOPATH is (on Linux) /home/username/go and you want to create a project named "gopro" and want to place it in "/home/username/go/src/github.com/user" you need to type in the Eclipse window: "/home/username/go/src/github.com/user/gopro". Everything should work without any problems afterwards.
I could not find an answer to this question. I've decided to use IntelliJ with the golang plugin and this solution works wonderfully.