I'm not saying it shouldn't work as you try to do it. I thing vgo is a very
early prototype many corner cases seem to be unsolved. Your problem arises
because the old mechanism (GOPATH) is not there anymore.
I actually think that your replace workaround should work, so maybe you
should file an
On 24-02-2018, flicaf...@gmail.com wrote:
> --=_Part_9366_348433021.1519468400573
> Content-Type: multipart/alternative;
> boundary="=_Part_9367_868487623.1519468400573"
>
> --=_Part_9367_868487623.1519468400573
> Content-Type: text/plain; charset="UTF-8"
>
> Vgo implements a pac
On 24-02-2018, Amnon Baron Cohen wrote:
> --=_Part_9094_478136164.1519461749739
> Content-Type: multipart/alternative;
> boundary="=_Part_9095_482511421.1519461749739"
>
> --=_Part_9095_482511421.1519461749739
> Content-Type: text/plain; charset="UTF-8"
>
>
>
> On Friday, 23 Febr
Vgo implements a package manager which is suppose to download dependencies
from some remote host.
It determines where to fetch the code by looking at the import path of the
dependency.
Hence All dependencies which are managed with the new vgo mechanism musst
follow this import path convention.
O
On Friday, 23 February 2018
>
>
> I work with GOPATH per project.
>
> Then I use to give them a one word path directly under src:
>
> $GOPATH/src/myapp
>
>
Go is a highly opinionated language assumes that you lay out your code as
described in https://golang.org/doc/code.html
If you decide to
