<p>I noticed, though according to the docs this is optional, that a lot of packages decide to just name all their own packages based off their github account name.</p>
<pre><code>import (
"fmt"
"github.com/user/stringutil"
)
</code></pre>
<p>Seems kind of weird versus say:</p>
<pre><code>import (
"fmt"
"user/stringutil"
)
</code></pre>
<p>Why? It just seems to unnecessarily long to include the 'github.com' portion in the package path/name as well. Can someone explain to me the purpose aside from name conflicts why this was a decision to someone who doesn't really know much about the history of the languge, etc...?</p>
<hr/>**评论：**<br/><br/>drvd: <pre><p>For the Go compiler these strings are opaque import paths, they have no meaning and for the Go compiler (and linker) you can use whatever you like.</p>
<p>And there is the go tool which is typically used to build, run install and download Go packages (the go tool invokes the compiler, linker, etc.).</p>
<p>The go tool subcommand get (go get <packagename>) <em>knows</em> about several public code repositories like github which makes such packages "go getable" which is very nice.</p>
<p>So this convention has nothing to do with the language but the typical tooling used to distribute, download and build Go code: the go tool.</p></pre>SaltTM: <pre><p>Ah, thanks. Guess that's convenient, I'm used to PHP's <a href="http://getcomposer.org" rel="nofollow">composer</a> where we'd <a href="https://getcomposer.org/doc/02-libraries.md" rel="nofollow">define all</a> the packages in a file and their versioning and use their namespace when necessary. Is there a way to manage packages from github repos without directly inserting them into the import or import aliases?</p></pre>izuriel: <pre><p>I know sometimes it becomes hard to distinguish bit composer is just a library that helps manage dependencies. There are similar third party options with Go such as glide (my personal favorite), Godeps and GB. </p>
<p>I don't think any of them offer you what you seek specifically but they do give you the ability to note version of the depend upon which can be used to get reproducible builds. </p></pre>SaltTM: <pre><p>Ah nice, may check those out.</p></pre>dlsniper: <pre><p>There's no (easy/sane) way to achieve this and you shouldn't even be bothered with it. The import path matters only one time: when you decise to use a package and that's it. Is it relevant if it has a gihub.com, bitbucket.org, google.golang.org or mydomain.org? That way at least you know when you read the package where your dependency comes from. </p></pre>SaltTM: <pre><p>Alright, thanks for the help.</p></pre>Consuelas-Revenge: <pre><blockquote>
<p>Is there a way to manage packages from github repos <strong>without directly inserting them into the import</strong></p>
</blockquote>
<p>You seem to be having some kind of issue... maybe it would help to tell us what that is instead of asking about potential solutions?</p>
<blockquote>
<p>or import aliases?</p>
</blockquote>
<p>It's not clear what you mean by this. It doesn't seem to make sense in this context.</p></pre>neoasterisk: <pre><p>Which <code>user/stringutil</code>?</p>
<ul>
<li><code>github.com/user/stringutil</code></li>
<li><code>bitbucket.org/user/stringutil</code></li>
</ul></pre>thewhitetulip: <pre><p>It isn't just about github, the thing about Go is that they didn't want something like Pypi maybe, and that's why it is easier to fetch remote repos if you name your package as the URL of the git repo.</p>
<p>you can have your own git server on the internet in place of github and it'll still work.</p>
<p>This doesn't mean that user/stringutil won't work, just that you won't be able to distribute the package since it won't understand where the user/stringutil is located (again because there is no pypi kind of thing for go)</p>
<p>But for private projects which you do not want to distribute over the internet you can surely use that kind of package name, go doesn't forbid us from doing so.</p></pre>nathj07: <pre><p>It is a convention now widely adopted, it makes guaranteeing uniqueness among imports easier, and having tried without it I find it simpler. If you use tools like go imports it becomes so easy you don't notice it.</p></pre>skidooer: <pre><p>When you run <code>go get</code> on your source to download dependencies, it also needs to know the hostname in which to connect to. Github isn't the only host out there. It is an import path, but also a URL, depending on which Go tool is reading it.</p></pre>Kipzy: <pre><p>I think it is like that because it is the first directory after your $GOPATH</p></pre>
