<p>I know golang doesn't support relative import. But I don't understand why.</p>
<p>I've read the golang's documentation on relative import: <a href="https://golang.org/cmd/go/#hdr-Relative_import_paths" rel="nofollow">https://golang.org/cmd/go/#hdr-Relative_import_paths</a></p>
<p>And this is the statement that confuses me:</p>
<blockquote>
<p>To avoid ambiguity, Go programs cannot use relative import paths within a work space.</p>
</blockquote>
<p>Seems like it's very easy to support relative import by simply remove a few lines from golang compiler source code, and I just did on my local installation:</p>
<pre><code> return setErrorPos(&perr, importPos)
}
- if p.local && parent != nil && !parent.local {
- perr := *p
- perr.Error = &PackageError{
- ImportStack: stk.copy(),
- Err: fmt.Sprintf("local import %q in non-local package", path),
- }
- return setErrorPos(&perr, importPos)
- }
-
return p
}
</code></pre>
<p>I don't get why go is trying to do this. Because it is <a href="http://stackoverflow.com/questions/10687627/relative-import-from-parent-directory#comment27559037_10688069" rel="nofollow">useful sometimes</a>.</p>
<blockquote>
<p>Relative paths are good for one (IMO critical) use case: dealing with forked repositories. If you fork someone's repo on github you'll have to update all of the import statements to refer to your copy, and then remember not to push those upstream (or expect that upstream would exclude them in the merge). Just gets sloppystrong text</p>
</blockquote>
<p>And I also found other complains, for example <a href="http://blog.mattbasta.com/things_that_make_me_sad_in_go.html#relative-package-imports" rel="nofollow">http://blog.mattbasta.com/things_that_make_me_sad_in_go.html#relative-package-imports</a></p>
<p>Other languages like python is fine with relative import, why go is trying to 'go' this way?</p>
<hr/>**评论：**<br/><br/>dlsniper: <pre><p>I'd go around this in another way. Why do you need relative imports? What critical benefits do they bring so that you must use them but you can't?</p>
<p>I've seen the comments that you cited but none of them seem to be answering those questions.</p>
<p>Also symlinks make usage of relative imports significantly more complex. </p></pre>jrkkrj1: <pre><p>Im in board with your questions. 99% of people dont have an issue not having relative imports. </p></pre>pony279: <pre><p>I would agree, considering those not comfortable with this may have already switched to other languages.</p>
<p>EDIT: </p>
<p>Actually I'm planning on switching to rust for future projects. I've been reading the documentation recently.</p></pre>TheMerovius: <pre><p>If you fork a repository, there are two possibilities: a) You intend to follow upstream and just want to add a patch or two (either for your own use, or to make a PR). You don't need to change any import paths, just use the same import path as upstream and maybe add your repo as a separate origin. Or b) you intend to fork the project. In that case, you need to update all the import paths, <em>because it's a new project</em>, so it shouldn't have the same name.</p></pre>pony279: <pre><blockquote>
<p>you intend to fork the project. In that case, you need to update all the import paths, because it's a new project, so it shouldn't have the same name.</p>
</blockquote>
<p>That's the pain.</p>
<p>Normally with other languages like python I don't need to worried about this.</p>
<p>I just found it's easier to just write code outside of <code>$GOPATH</code>, which would allow relative import. It's ok if I'm not trying to write a library, because nobody is gonna import my code which contains relative import.</p>
<p>Another option is to have per <code>$GOPATH</code> per project. But considering the effort required for setting up a project and <code>go get</code> each time without a user-wide cache, I'll just skip this one.</p></pre>TheMerovius: <pre><blockquote>
<p>Normally with other languages like python I don't need to worried about this.</p>
</blockquote>
<p>Yes, you do. If you upload a new project to npm/cpan/whatevs, you need to rename it and people who want to import it need to use the new name.</p></pre>pony279: <pre><p>No I don't. In this case for example, I will never need to change the code inside this library when forking. It does afect the client when the library name is changed.</p>
<pre><code>somelib.py
module1/__init__.py
</code></pre>
<p>In somelib.py:</p>
<pre><code>from . import module1
</code></pre></pre>dmikalova: <pre><p>Go is focused on simplicity even if it means having to type a few more characters. The ambiguity that you referenced is not trying to prevent ambiguity for the compiler - as you noted other languages have shown that's not a problem - but for the user. Having all http libraries differentiated is pretty nice - it also means you know where to go to download the package (go get) and where to find documentation and file issues. Those are pretty good advantages for just having to type a few extra characters.</p>
<p>Finally, you probably want to use goimports with your editor of choice - it'll automatically search your Go path and import matching libraries when you start using them in your code. This is another tool that'd be a lot less simple to implement with relative paths.</p></pre>pony279: <pre><p>I don't think it's making things simpler.</p>
<p>Because go do allows relative import if I'm not inside <code>$GOPATH</code>. It's twisted and in-consistent behavior.</p>
<p>EDIT:</p>
<blockquote>
<p>Because go do allows relative import if I'm not inside <code>$GOPATH</code></p>
</blockquote>
<p>Recently I do have a project finished outside <code>$GOPATH</code>. (it's simpler to start a project this way, <code>$GOPATH</code> is just a cache for the dependencies I've downloaded)</p></pre>tgulacsi: <pre><p>No need for relative import for forks:
a) use git remotes (<a href="http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html?m=1" rel="nofollow">http://blog.campoy.cat/2014/03/github-and-go-forking-pull-requests-and.html?m=1</a>)
b) use the vendor/ folder.</p></pre>jrkkrj1: <pre><p><a href="http://stackoverflow.com/questions/14323872/using-forked-package-import-in-go" rel="nofollow">http://stackoverflow.com/questions/14323872/using-forked-package-import-in-go</a></p></pre>jechols: <pre><p>I feel @dmikalova's response answers your question best.</p>
<p>It may be helpful for your own projects to consider other options, however, which can be more portable for others.</p>
<p>I used to write complex Makefiles, and more recently switched to "gb" for projects (packages I expect others to use, on the other hand, have to conform). But I suspect that in general, a project-focused GOPATH can give you something similar to local imports. The "gb" approach does some magic, but the gist of it is that your GOPATH is set to a project directory. Your packages live under "src", and third-party dependencies live under "vendor/src". If you don't use something like "gb", you end up having to manage your dependencies more manually, and build your code "more weirdly" (e.g., <code>go build ./src/cmd/blah</code>), but it's certainly possible to treat a directory as a self-contained project.</p>
<p>To everybody else: please consider how your responses come across. By dismissing OP's concerns it just makes the community look like holier-than-thou snobs. It's not constructive to tell the OP that most people don't have an issue or that there are only X possible use-cases. If you can't answer the question, please don't chime in just to say the asker is wrong.</p></pre>twinkiac: <pre><p><a href="http://i.imgur.com/IfFk94K.jpg" rel="nofollow">@dmikalova's latest tweet</a></p>
<p><a href="https://twitter.com/dmikalova" rel="nofollow">@dmikalova on Twitter</a></p>
<h2></h2>
<p><sup>i</sup> <sup>am</sup> <sup>a</sup> <sup>bot</sup> <sup>|</sup> <sup><a href="https://www.reddit.com/message/compose/?to=twinkiac" rel="nofollow">feedback</a></sup></p></pre>XTL: <pre><p>Elative paths sound so nice. </p></pre>: <pre><p>[deleted]</p></pre>pony279: <pre><p>Why the down-vote?</p></pre>TheMerovius: <pre><p>Because, apparently, I accidentally submitted this twice due to the shitty internet in this hotel. Didn't notice so far ^^</p></pre>
