You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more of a question rather than an issue.
Currently, when an import path isn't vendored and also doesn't exist in GOPATH or GOROOT, vndr would typically exit with exit status=0.
Now, this will fail the package compilation, so it gets caught there.
But would it be good if we are to exit with non zero code if such situation arises?
The text was updated successfully, but these errors were encountered:
Madhur1997
changed the title
vndr <pkg> or vndr should return error when import path is not vendored and not existent in GOPATH, GOROOT
vndr <pkg> or vndr should return error when import path is not vendored and not existent in GOPATH, GOROOT.
Jun 21, 2020
I am not sure I understand the problem. I thought vndr <pkg> were supposed to download package to vendor directory, though I might remember wrong.
Do you have example repo where I could try that?
Sorry, I wasn't clear enough.
Consider a scenario:
Suppose I create a go dir, add some imports, then I perform vndr init. This will install all the referenced imports in the vendor dir.
Now, I add another import say package 'A'.
I don't have 'A' on local file system yet. Now if I issue just vndr, this will be successful.
Now, in such a situation, the compilation would fail obviously.
But, I was wondering if it was better to log the missing package as well.
Currently, in this workflow, we hit the following case in 'collectAllDeps' method.
if err != nil {
if strings.Contains(err.Error(), "cannot find package ") && dlFunc != nil {
ipkg, err = dlFunc(imp)
}
}
Here, dlfunc is nil, so we just end up ignoring the 'cannot find package' error.
This is more of a question rather than an issue.
Currently, when an import path isn't vendored and also doesn't exist in GOPATH or GOROOT,
vndr
would typically exit with exit status=0.Now, this will fail the package compilation, so it gets caught there.
But would it be good if we are to exit with non zero code if such situation arises?
The text was updated successfully, but these errors were encountered: