<p>Hi guys. </p>
<p>Could someone explain the relationship between GitHub and Go?</p>
<p>I'm pretty new to Go, and have recently been browsing the source code of some example applications. One thing that stands out is the GitHub import statements. Is this a method of removing the need for a package manager, and simply declaring the source of the library so the compiler knows where to look? Or is this just a namespace (similar to using a domain, or an email address in Java)?</p>
<p>I'm not sure why (maybe brainwashing), but to me, something doesn't sit right with hardcoding dependancy repositories directly in the source code...</p>
<hr/>**评论：**<br/><br/>natefinch: <pre><p>So... as far as <code>go get</code> is concerned, the import statement is assumed to be a URL for git etc. <code>go get</code> will see <code>import "foo.com/bar/baz"</code> and try to get that code (there's various ways it tries, but most of the time, just trying that as the git remote works). <code>go get</code> then puts that repo at $GOPATH/src/<importpath>, so for the above, go get effectively does</p>
<pre><code>mkdir -p $GOPATH/src/foo.com/bar/baz
git clone https://foo.com/bar/baz $GOPATH/src/foo.com/bar/baz/
</code></pre>
<p>and then it does the same recursively for all the dependencies specified by import paths in that package. And then it runs go install on $GOPATH/src/foo.com/bar/baz</p>
<p>Aside from <code>go get</code>, none of the rest of the go tools understand URLs or source control at all. They all simply work with files on disk. To all the rest of the tools, the import path is simply a path under $GOPATH/src. So for example, <code>go build foo.com/bar/baz</code> knows to go look for source code under $GOPATH/src/foo.com/bar/baz and try to build it. It doesn't know or care how the files got there, it just builds them. Thus, if you want to, you can put your own code wherever you want under gopath. You can put your code under $GOPATH/src/git/sucks/who/needs/vcs/anyway and you'll be able to import that code from any go file on your machine by having <code>import "git/sucks/who/needs/vcs/anyway"</code> in your code, and <code>go build</code> will understand it and build it.</p></pre>davecheney: <pre><blockquote>
<p>I'm not sure why (maybe brainwashing), but to me, something doesn't sit right with hardcoding dependancy repositories directly in the source code...</p>
</blockquote>
<p>It's not hard coded. The argument to the <code>import</code> statement is opaque from the POV of the language. <code>go get</code> treats the import statement as a potential URL to fetch code from, <code>go build</code> (strictly speaking, the compiler) treats it as a path on disk to find a compiled version of the dependency.</p>
<p><a href="http://getgb.io/rationale/" rel="nofollow">Read more</a></p></pre>quiI: <pre><p>It's nothing to do with Github, it is a means of fetching dependencies from a URL. For instance, you can also find go repositories in bitbucket.</p></pre>bankslain: <pre><blockquote>
<p>I'm not sure why (maybe brainwashing), but to me, something doesn't sit right with hardcoding dependancy repositories directly in the source code...</p>
</blockquote>
<p>There are two Go topics that have been discussed to death - generics and dependency management. Just Google it I'm sure you'll find plenty of discussions about the rationale.</p></pre>face__dancer: <pre><p>the problem isn't so much these URLs, but the way packages are fetched when you use "go get" command line. It doesn't matter if a package is called "foo" or "example.com/foo" , you cannot target a specific version of "example.com/foo" with go get and force foo dependencies to be a specific version. </p>
<p>The go team didn't clearly think about the consequences of these choices when they created the go tools, a pattern that is seen often in go ecosystem. </p>
<p>Now the argument is "go get" isn't a package manager then what is it ? it certainly does fetch dependencies which is half the job of a package manager. the second argument is "it works at google", which is a bit scary because it means the community needs are not a priority , if it works for google it's good enough. A third argument is "well fix it in userland", which means people using incompatible package managers that don't work with go get at first place. Finally the vendoring argument : but vendoring isn't package version management.</p>
<p>I like go, but I'm now heavily questioning my investment in the language, due to some kind of denial coming from the go team and also some part of the go community that defends these choices to death. Instead of coming clean and saying this or that choice was a mistake because it doesn't scale, it's spun as a kind of "philosophy". The right attitude now is caution , and just look at how the language an its tools evolve up til v2 .</p></pre>KimIlYong: <pre><p>And thats what i like! I do not want a package manager to do some magic. Actually i do not want to have a package manager at all! Go get does all i want - if there is some version mismatch, good, i have to sort it out. I dont want to have some version issues pop up later in production.</p></pre>thomasfr: <pre><p>Well, the reason to have a package manager is to avoid having version issues, for example avoiding the risk of two developers having slightly different versions of something installed.
It's not usually a big issue in practice but it probably already have caused serious problems for someone somewhere. </p></pre>thomasfr: <pre><p>Since there are tools like godep/gb/gost it's even less of an issue. Maybe in a future were some go packages have grown really large it might bog be as feasible to just throw all of them into a single git repo but thats a later problem..</p></pre>binaryblade: <pre><p>Ok so there is a whole lot of discussion on how to correctly deal with dependencies. The way go natively deals with it is to directly check out imports by the path given in the import. It is a domain address.</p></pre>
