<ol dir="auto">
<li>What version of Go are you using (<code class="notranslate">go version</code>)?<br>
1.6</li>
<li>What operating system and processor architecture are you using (<code class="notranslate">go env</code>)?<br>
ubuntu 16.04 x86_64</li>
<li>What did you do?<br>
I want to build a go project using gitlab-ci. The project gets clone on the build machine in /build/project, which is not inside the go path. The build fails due to import errors.<br>
I reproduced this manually: moving a project outside the GOPATH leads to ignoring the vendor folder.</li>
<li>What did you expect to see?<br>
go searching for imports in the vendor directory</li>
<li>What did you see instead?<br>
The vendor directory is ignored and go only searches in GOROOT and GOPATH</li>
</ol>
<p dir="auto">Over the years, when helping people approaching existing Go projects (colleagues, friends, etc.) the number one problem is of course that they don't know about <code class="notranslate">GOPATH</code>, they don't have one configured, and they expect to be able to clone an existing project wherever they want on the disk, and be able to build it. I think the problem statement is clear and the problem is well known.</p>
<p dir="auto">With the introduction and adoption of the vendoring folder, most Go applications do not even require <code class="notranslate">go get</code> to run, after the initial clone: all the source code required to compile them is already available in the source tree; it's just that the Go tool doesn't know where to look if <code class="notranslate">GOPATH</code> is not defined.</p>
<p dir="auto">Instead of suggesting a default <code class="notranslate">GOPATH</code> (which does not solve the fact that people will need to find out about it and use it somehow), I suggest that we change the Go toolchain in multiple steps (each one can be independently released as an experiment):</p>
<ul dir="auto">
<li><strong>STEP 1</strong>: If <code class="notranslate">GOPATH</code> is not set, the Go tool will use any existing <code class="notranslate">./vendor</code> directory as it was part of the <code class="notranslate">GOPATH</code>. (I think of this as defaulting <code class="notranslate">GOPATH/src</code> to <code class="notranslate">./vendor</code>).  At least <code class="notranslate">go build</code> and <code class="notranslate">go run</code> are guaranteed to work. Anything else, like <code class="notranslate">go install</code> and <code class="notranslate">go get</code>, would fail with an error pointing to the <code class="notranslate">GOPATH</code> documentation.</li>
<li><strong>STEP 2</strong>: if <code class="notranslate">GOPATH</code> is not set, the Go toolchain would be updated to use <code class="notranslate">$HOME/.gopkg</code> (or similar) as <code class="notranslate">pkg</code> directory. This would allow other commands to work (e.g.: <code class="notranslate">go build -i</code> or <code class="notranslate">go install</code>).</li>
<li><strong>STEP 3</strong>: if <code class="notranslate">GOPATH</code> is not set, <code class="notranslate">go get</code> (or the new package manager, if/when it gets released) would be modified to download packages directly into <code class="notranslate">./vendor</code></li>
</ul>
<p dir="auto">As shown in Step 2, I think this proposal would also interact well with the existing proposal/discussion of dropping <code class="notranslate">pkg</code> in favour of a hidden cache directory, as that would move things further into the direction of not needing <code class="notranslate">GOPATH</code> anymore for a whole class of development; in fact, this functionality could be prototyped in this specific scenario of "<code class="notranslate">GOPATH</code> not defined", where it would make sense to do it without facing the bigger discussion of deprecating <code class="notranslate">pkg</code> for a normal <code class="notranslate">GOPATH</code> scenario.</p>
<p dir="auto">As shown in Step 3, I also think that this might interact well with the new package manager. I saw many people requested that the new package manager ought to be able to download dependencies directly into the vendor folder (like <code class="notranslate">govendor</code> and <code class="notranslate">glide</code> can do); if this functionality lands in the new package manager, it would be a perfect default for the "<code class="notranslate">GOPATH</code> not defined" scenario described here. Alternatively, it might make sense to discuss modifying <code class="notranslate">go get</code> to have this behaviour.</p>
<p dir="auto">I think this proposal is incremental, backward-compatible, doesn't affect existing users that successfully use <code class="notranslate">GOPATH</code>, and allow beginners to approach existing Go codebases without stumbling too soon into <code class="notranslate">GOPATH</code>.</p>