You are right. That is very similar except that, instead of having a convention for naming directories, there should exist a .goenv in the working directory (or a up parent). In this .goenv file a go-path can be set - and maybe other go env vars.
This way, it is possible to take advantage of having multiple paths in a $GOPATH (-like) env var. The go tools will work with the first one. They also look into the second path or other paths after that, if a package can not be found inside the first path. In short, the base idea is being able to set the first path in a list of paths (inside the $GOPATH var), in a project-specific way. And it is exactly how go tools use $GOPATH currently. The only difference is there should be another way to introduce go-path to go tools, other than $GOPATH env var. On Thursday, April 19, 2018 at 5:28:39 PM UTC+4:30, Paul Jolly wrote: > > I think you're getting at something similar to: > > > https://docs.google.com/document/d/1Ee8POHVeo3N6c1pgiubdWoUJoYkD5cwY3p8rqonRY0o/edit > > Implemented roughly here: > > https://github.com/myitcv/go > > This was itself similar to/influenced by: > > https://github.com/golang/go/issues/17271#issuecomment-268301191 > > In any case I think all of this becomes irrelevant in the context of vgo: > > https://research.swtch.com/vgo > > On 19 April 2018 at 13:48, Kaveh Shahbazian <kaveh.sh...@gmail.com > <javascript:>> wrote: > >> Is it possible to tell go tools to get the go-path from a source other >> than $GOPATH? >> >> Notes: >> >> Assuming the answer is no, I wish it was possible. >> >> For example when running a go command from the current directory, it go >> search the current directory, or goes up, until it finds a (for example) >> *.goenv* file, in which the GOPATH for current directory is specified. >> >> And the system-wide $GOPATH would act as a fall-back option, an umbrella >> root. >> >> This way the current project can have all of its stuff under the >> directory that contains the specified .goenv without interfering with other >> packages. >> >> Now if the current package (A) has two dependencies B and C and B uses a >> different version of C, then B can simply resides in a parallel directory >> to the current directory and be found in the system-wide $GOPATH. >> >> But go tools would always look for .goenv first. >> >> Seems to occupy the same amount of disk space as any other way of >> managing packages. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
