Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/vgo: Is it possible to vgo install a custom library outside of GOPATH? #25639

TerrenceHo opened this issue May 30, 2018 · 5 comments


Copy link

commented May 30, 2018

Perhaps I missed this in rsc's vgo introduction, but how is vgo install supposed to work when you install a custom package outside of the GOPATH?

What version of Go are you using (go version)?

go version go1.10 darwin/amd64
go version go1.10 darwin/amd64 vgo:2018-02-20.1

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/qj/y8h5yl817zg5lj742cndn67m0000gq/T/go-build401971324=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I recreated the stringutil package from the "How to Write Go Code" in a directory outside of the GOPATH, but added import statements. The stringutil2 is located in ~/Desktop/stringutil2. File is below.

package stringutil2 // import ""
// Package stringutil contains utility functions for working with strings.

// Reverse returns its argument string reversed rune-wise left to right.
func Reverse(s string) string {
	r := []rune(s)
	for i, j := 0, len(r)-1; i < len(r)/2; i, j = i+1, j-1 {
		r[i], r[j] = r[j], r[i]
	return string(r)

I added an empty go.mod file. I then attempted a vgo build in this directory. The go.mod file has the module name correctly added.

$ vgo build
$ cat go.mod

Now that it builds correctly, I attempt to use vgo and install it, still attempting to follow the tutorial.

$ vgo install
go install: no install location for directory /Users/kho/Desktop/stringutil2 outside GOPATH
	For more details see: 'go help gopath'

What did you expect to see?

I expected this package to be installed under $GOPATH/pkg/darwin_amd64/

What did you see instead?

It errors out, saying it cannot locate the GOPATH. The vgo proposal mentioned being able to write Go code anywhere, not just within the GOPATH. As such, I thought this would succeed, since I had implemented the correct go.mod file. Additionally, if you try installing a main package, i.e. an executable, vgo install succeeds.

@gopherbot gopherbot added this to the vgo milestone May 30, 2018


This comment has been minimized.

Copy link

commented Jun 1, 2018

/cc @myitcv , @kardianos - Not sure if this is to be interpreted as a question or an issue.


This comment has been minimized.

Copy link

commented Jun 1, 2018

@TerrenceHo - is there a reason you need to vgo install this package? i.e. what dependency do you have on $GOPATH/pkg/darwin_amd64/

If you are writing code outside of GOPATH (as you are) then vgo install will indeed fail.


This comment has been minimized.

Copy link

commented Jun 1, 2018

@myitcv No, I just thought that writing a package outside of GOPATH would install into the correct directory in the GOPATH pkg tree based on the import module name, due to rsc's statement that vgo would deprecate GOPATH. I was just experimenting with vgo. So in the future, we should continue to write libraries inside the GOPATH/src tree?

@agnivade This is more of a question than an issue, although if vgo should support installing a non main package from outside GOPATH, then it could be considered an issue.


This comment has been minimized.

Copy link

commented Jun 2, 2018

So in the future, we should continue to write libraries inside the GOPATH/src tree?

As I understand things, GOPATH is no longer a requirement; I'm not entirely clear that it will disappear entirely though. So, as per the vgo examples, you don't need to develop within GOPATH, but you can (for now).

If you are developing outside GOPATH, then vgo install should not be required (because otherwise what would the target of the install be?).

If you are developing inside GOPATH, the vgo install will (for now) behave like go install does.

Tools like gocode currently rely on the $GOPATH/pkg tree to function, and hence rely on code being developed inside GOPATH. But there is work underway that will help to sever the dependency of such tools on $GOPATH/pkg and hence allow you develop all of your Go code outside GOPATH.


This comment has been minimized.

Copy link

commented Jun 4, 2018

I believe Paul's answer clarifies things as working as intended. Hence closing this.

Feel free to comment if you disagree.

@agnivade agnivade closed this Jun 4, 2018

@golang golang locked and limited conversation to collaborators Jun 4, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
4 participants
You can’t perform that action at this time.