<p>For example, in the gitlab ci multirunner project there are import statements like (<a href="https://github.com/ayufan/gitlab-ci-multi-runner/blob/master/commands/multi.go#L17">example</a>)</p>
<pre><code>import "gitlab.com/gitlab-org/gitlab-ci-multi-runner/common"
</code></pre>
<p>If I "go get" the project, I can build it. But when I fork it and put it under "src/mystuff/gitlab-ci-multi-runner", I get build errors like</p>
<pre><code>imports gitlab.com/gitlab-org/gitlab-ci-multi-runner/commands: unrecognized import path "gitlab.com/gitlab-org/gitlab-ci-multi-runner/commands"
</code></pre>
<p>If this is considered best practice in go, how to deal with this use case (fork)? If that's not the recommended way to use imports, what should I use for my own projects?</p>
<p>Thanks.</p>
<hr/>**评论：**<br/><br/>nstratos: <pre><p>I think using something like:</p>
<pre><code>git remote add fork https://gitlab.com/you/gitlab-ci-multi-runner.git
</code></pre>
<p>on the original project code might solve your problem. Check out this <a href="http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html" rel="nofollow">post</a> of Francesc Campoy explaining the procedure.</p></pre>cptcomic: <pre><p>Interessting. Thanks. If would follow this post and make changes in "server.go", and someone would "go get github.com/you/cooltool.git" wouldn't they also "go get" the original version and use "server.go" from this version?</p></pre>nstratos: <pre><p>You work directly on the original version. Your fork only exists on github. When you finish editing server.go then instead of pushing to the original, you push to your fork with: </p>
<pre><code>git push fork
</code></pre>
<p>Your fork will then have the new version of server.go and finally you can make a pull request to the original repository to accept your new server.go from your forked repository.</p></pre>izuriel: <pre><p>This solution works fine if you're working on bug fixing or feature improvements to a repository. This wasn't mentioned in the question here so I didn't reply with any help as to solving this problem but explained why the issue questioned was occurring and it's resolution.</p>
<p>Again, this is a great way to go about working on another project but doesn't solve the issue of "I've forked it to be significantly different or to be my own iterpretation" (in which case import paths will have to change).</p></pre>izuriel: <pre><p>You changed the path of the source. You will need to rewrite those imports to the new path. The key here is that the error is informing you the path your trying to import (original) doesn't exist (because you moved the code to a different path)</p></pre>cptcomic: <pre><p>Thank you. I understand the problem. New to go, I just find it hard to believe, that hardcoding this kind of information into the source code, is the way to "go".</p></pre>xrstf: <pre><p>It is the way to go. Relative imports don't work as you would expect, so we're stuck with this. If it bothers you, you are out of luck: If it's no problem for Google internally, they don't give a flying sh_tf_ck about it. Just look at the package manager debate where all Google is saying is "we don't need multiple gopaths/versions in our world, so f* you!"</p>
<p>Sorry for being so negative, but Google's attitude is one of my main pain points with Go.</p></pre>izuriel: <pre><p>Google pays the developers of Go to build a language to meet the needs of Certain Google development teams so it would seem perfectly logical that an internal tool is solely based an their needs. Then they have this tool away to be used by other people but O fail to see where that would really require them to bend to the communities will, they could very well have kept this locked away behind closed doors at Google and never released it.</p>
<p>If they don't need, it probably won't be added. It's the benefit of owning the software. If it bothers that much you can seek out other languages as options for your projects - or if you work on Go you would have a harder time getting away from it. </p>
<p>Berating Google does nothing productive and paints you in a negative light. I don't like some things about Go, but that's what makes Go Go and not something else so I suck it up and move on with my life. </p></pre>xrstf: <pre><p>I do seek out other languages, but at the same time I can see Go's strong points. I didn't say that Go was an entirely bad language! Strong Windows support, minimal syntax, goroutines and super easy deployments are things I really enjoy in Go and are the reasons why I still use it for my projects. For situations where I need smaller binaries, I'm looking at Nim (now that 1.0.0 is released). For web stuff, PHP is still my main choice.</p>
<p>The things I don't like about Go are things like the ones I mentioned. I can't fork a Go package without also telling my users "oh yeah, you need to go-get it and then move it to a different spot" (or maybe I'm overlooking cleverness in go get and it actually looks at the source to determine the target download directory). I can't keep a specific version of some dependency without using 3rd party tools or resorting to "git commit all the things!".</p>
<p>Maybe I expressed my concern badly in the previous post. What I wanted to say is that I can feel Google's strong influence on the language and its ecosystem, and not all of Google's choices are necessarily ones that are useful for the "general public". If you choose Go, you are at the mercy of Google. And in the last years, that has proven problematic for me.</p>
<p>(Rust, for comparision, feels much more community-influenced, even though it's steered by Mozilla. Not saying that Rust is better or worse than Go.)</p></pre>izuriel: <pre><blockquote>
<p>Rust, for comparision, feels much more community-influenced, even though it's steered by Mozilla. Not saying that Rust is better or worse than Go.</p>
</blockquote>
<p>Rust does have a significant amount of community involvement, the difference in my eyes (as I have seen and read) is that Mozilla opened up Rust to the public and then significant amounts of community contributions have been made, including developing or determining language behaviors and features.</p>
<blockquote>
<p>Maybe I expressed my concern badly in the previous post.</p>
</blockquote>
<p>It sounded rather hostile to me, you have my apologies if that was incorrect assumption and my response was out of line.</p>
<blockquote>
<p>Nim (now that 1.0.0 is released)</p>
</blockquote>
<p>I didn't follow it much because I assumed this was further away, this is good to hear and I'll be playing with it again.</p>
<blockquote>
<p>If you choose Go, you are at the mercy of Google.</p>
</blockquote>
<p>Such is the world in which live. Although, IMHO, it's the same ecosystem with Java and Oracle. While recent developments have helped to bring very necessary (this is all IMHO) features to the language to make it an attractive option in the current landscape they still don't provide a native package manager with the language. C# is very similar, although generally viewed outside of these problems as most C# developers I've dealt with in the past wear rather large rose-colored glasses (do not read into this that I hate C#, that's not what I'm talking about) when it comes to that language and it's platform. Although Microsoft has begun pushing really hard into a very needed area for them, I'm sure Google will work on implementing things as they come around.</p>
<p>Package management has been discussed and the last thing I read from the Go team (which was actually a while back, so it's possible it's no longer true) there were talks about vendoring capabilities coming packaged in the go toolchain come Go 1.5 release.</p>
<blockquote>
<p>I can't fork a Go package without also telling my users "oh yeah, you need to go-get it and then move it to a different spot" (or maybe I'm overlooking cleverness in go get and it actually looks at the source to determine the target download directory).</p>
</blockquote>
<p>Not sure I understand. The only requirement thing that has to change are import paths internal to the project itself. If you fork "github.com/someuser/badass-project" then all imports of that nature must change, the should change to the new path which would be "github.com/awesome_user/badass-project" instead. To your consumers, nothing changes. They can still "go get github.com/awesome_user/badass-project" and the go toolchain creates the necessary directory structure (in this case, it would be $GOPATH/src/github.com/awesome_user/badass-project) and any imports that specify that path pull in your fork. You can have this installed alongside the original repository as well because the paths are unique to each project and therefore you can import both versions simultaneously (although package aliases would be needed).</p>
<p>If you clone projects, just path them the same way. If you want clone "github.com/someuser/badass-project" then do these simple steps:</p>
<pre><code>$ mkdir -p $GOPATH/src/github.com/someuser
$ cd $GOPATH/src/github.com/someuser
$ git clone https://github.com/someuser/badass-project
</code></pre>
<p>And boom, done, import away like nothing every happened.</p>
<p>P.S. go get also fetches from a large number of other remote source control options.</p>
<p><strong>tl;dr</strong> I don't care if you're lazy. Read the damn thing.</p></pre>xrstf: <pre><blockquote>
<p>Not sure I understand. The only requirement thing that has to change are import paths internal to the project itself. If you fork "github.com/someuser/badass-project" then all imports of that nature must change, the should change to the new path which would be "github.com/awesome_user/badass-project" instead. To your consumers, nothing changes.</p>
</blockquote>
<p>I have stayed away from package managers for Go because it seems the community has not yet settled on one (I hope that happens, it did <em>wonders</em> to the PHP world). That's why I haven't used go get extensively, so sorry for my lack of RTFM.</p>
<p>How should I handle this scenario: I have some upstream package (<code>github.com/upstream/lib</code>). I have some patches and so I forked the library to <code>github.com/me/lib</code>, patched it and created PRs. Now I'm waiting for them to be merged. What am I supposed to do in the meantime? It looks like I either have to</p>
<ul>
<li>document that you have to <code>go get github.com/me/lib</code> (and <em>not</em> use the upstream one, because that one has bugs) and that you have to place it into <code>$GOPATH/src/github.com/upstream/lib</code>).</li>
<li>document that after getting <code>upstream/lib</code>, you need to add my fork as a remote and pull from that as well.</li>
<li>commit the library to my project as well, with all the issues that brings.</li>
</ul>
<p>You are absolutely correct, forking with the intent of permanently diverging from the original project is no issue, because the paths/imports change accordingly.</p>
<p>This all looks to me as a drawback Go inherits from directly linking the code origin (URL) with the package name. Sure it's easy and works for most situations (it hasn't bitten me yet in Go, but something like this would have caused problems many times with my PHP projects), but at the same time it <em>prevents</em> some more advanced approaches to handling packages. But then....</p>
<blockquote>
<p>Package management has been discussed and the last thing I read from the Go team (which was actually a while back, so it's possible it's no longer true) there were talks about vendoring capabilities coming packaged in the go toolchain come Go 1.5 release.</p>
</blockquote>
<p>This excites me indeed :)</p></pre>izuriel: <pre><p>To the scenario given, unfortunately, there are no elegant ways to handle that. This is, as you have mentioned, an unfortunate side effect of the way Go handles things (remember, I'm not here proclaiming Go is almighty and the Go way is correct because it's Go). That being said though, it does have some relatively simple solutions like the ones you mentioned, although this falls onto the library consumer to accomplish those steps. We'll see if something comes out of.</p>
<p>I can definitely understand your hesitation to pick a package manager, I myself have used Gom and Godep for projects for experimentation. Having a ruby background I definitely prefer Gom (Gomfile ~= Gemfile) although I found Godep was relatively simple. Unless Go itself pulls away from the workspace concept (which I doubt it will) I stay away from tools like wgo and gb (I'm not saying anything negative about either project) but they both have their own takes on how a project should be structured. If either of those options find a home as the "official" way, I won't have issues with them - but in the flux I use what's comfortable and easy for me and the guys I work with.</p></pre>izuriel: <pre><p>It is only slightly different than other languages with import paths. It's not like anything has been <em>hardcoded</em> at all. It's an import path that expects that project to be set up the way it was written. The workspace is a key feature that allowed for simplification of tools. </p>
<p>Making things truly simple usually means that certain features must be done away with. Here, importing is dead simple and the only sacrifice made was expected locations of those files. </p></pre>cptcomic: <pre><p>I'm not arguing, just want to learn the go way - I'm sure there are advantages I have yet to discover. </p>
<p>Still, opening a bunch of files and changing the same string, is, what I call, hardcoded. </p></pre>izuriel: <pre><p>You should invest in a tool that automates that for you. </p></pre>cptcomic: <pre><p>Renaming things once is easy. In general, dealing with change (e.g. merging upstream), is what makes hardcoded stuff difficult to handle.</p>
<p>It's something every programmer tries to avoid. That's why I was asking, if there is some other way. Thank you, for your explanations.</p></pre>izuriel: <pre><p>Sorry if I came off as hostile at any point, it was not my intention.</p></pre>cptcomic: <pre><p>I didn't perceive it as hostile at all. I really appreciate your help.</p></pre>
