CODEWITHSUNDEEP
go
Apin
Apin

Reputation: 2668

Golang workspace for a project

I have a golang project and I put the code somewhere in git server. All my code are now on $GOPATH/mygitserver/folder/.

Everything is goods until the time that the gitserver is changes the url, so I need to replace all import to new gitserver url. So, i don't want to have it again in the future and want to change the way it works.

So instead of push the package only to my git server, now I am planning to upload the entire workspace to git (exclude the external library). So, I will have a package direcly to src folder (example : src/mypackage). So, when I change the gitserver url, everything will still works.

The question is : is it a good practice to do it (upload the workspace to git)? Or do we have another option?

And also it comes with another problem that not exist before. So, after I clone my workspace, I have to call "go get" for all of my library used by the project. (This not happen before because when I call go get mygitserver/package, Golang automatically download the dependency). Is there any way to make all the dependency downloaded my just one command?

Upvotes: 0

Views: 640

Answers (1)

user1087001
user1087001

Reputation:

If you expect your server to move frequently one possible solution is to use a vanity import path.

Vanity import paths allow you to keep your code at an import path on a domain you own which redirects you to the location where the code is stored. For instance, if you host your code on Bitbucket but are worried you might move in the future and you own the domain example.net, you could host your code such that you'd import it with import "example.net/myproject" and behind the scenes the go get tool would fetch it from Bitbucket. To do this, you must serve a document on the domain you want that contains a custom meta tag of the form:

<meta name="go-import" content="import-prefix vcs repo-root">

So for instance serving the following HTML file at example.net/myproject would redirect go get to clone the provided Bitbucket URL (it could also of course point to any other Git service including your own):

<meta name="go-import" content="example.net/myproject git https://bitbucket.org/myname/myproject.git">

To configure Nginx to serve these redirects, a configuration like the following can be used (replacing myPackage and the URLs with your projects name and URLs, of course):

location ~ /myPackage/[a-z][a-z0-9]* {
    if ($args = "go-get=1") {
        add_header Content-Type text/html;
        return 200 '<meta name="go-import" content="$host/myPackage git https://bitbucket.org/myName/myPackage.git">';
    }
    rewrite ^ https://mygithosting.example.org/myName/myPackage? permanent;
}
location ~ /myPackage$ {
    if ($args = "go-get=1") {
        add_header Content-Type text/html;
        return 200 '<meta name="go-import" content="$host/myPackage git https://mygithosting.example.org/myName/myPackage.git">';
    }
    rewrite ^ https://mygithosting.example.org/myName/myPackage? permanent;
}

Now any time you move your Git server, you can just change the URL in the meta tag.

If you're worried about some users importing directly from your Git server and others using the vanity import path, you can also set this path as the packages canonical import path. Canonical import paths are specified as special comments on the package line in one file of a Go program (it doesn't matter which one). They look like this:

import mypackage // import "example.com/mypackage"

Now if the above code is actually hosted somewhere else and someone tries to import it directly, go get will complain:

$ go get mygithosting.example.org/myName/myPackage package mygithosting.example.org/myName/myPackage: code in directory /go/mygithosting.example.org/myName/myPackage expects import "example.com/mypackage"

Upvotes: 3

Related Questions