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

glide rebuild does not work with vendored packages #81

Closed
nii236 opened this issue Sep 16, 2015 · 6 comments
Closed

glide rebuild does not work with vendored packages #81

nii236 opened this issue Sep 16, 2015 · 6 comments
Labels
Milestone

Comments

@nii236
Copy link

nii236 commented Sep 16, 2015

If I have a project located at:

$GOPATH/src/nii236/project1

With an existing .yaml file, and I run glide up, it will fetch all the vendor packages.

I then run glide rebuild in order to get the .a files in the $GOPATH/pkg folder so that I can use gocode autocompletion.

Here is what I get:

[INFO] Building dependencies.
[INFO] Running go build github.com/UserName/Repo
[WARN] Failed to run 'go install' for github.com/UserName/Repo: can't load package: package github.com/ChimeraCoder/Repo: cannot find package "github.com/ChimeraCoder/Repo" in any of:
    /usr/local/Cellar/go/1.5/libexec/src/github.com/UserName/Repo (from $GOROOT)
    /Users/nii236/Go/src/github.com/UserName/Repo (from $GOPATH)

The issue here is that glide rebuild should run go install on the project1/vendor path explicitly. So instead of running:

go install github.com/UserName/Repo

I manually run:

go install ./vendor/github.com/UserName/Repo

This, however, still does not work. go install will put the .a files into the following location:

$GOPATH/pkg/darwin_amd64/github.com/nii236/gank/vendor/github.com/Username

Which is the wrong path!

@mattfarina
Copy link
Member

@nii236 Thanks for the bug report. I'll take a look at this case. I have an idea what's causing this error.

@mattfarina mattfarina added the bug label Sep 16, 2015
@mattfarina mattfarina added this to the 0.6.0 milestone Sep 16, 2015
@nii236
Copy link
Author

nii236 commented Sep 17, 2015

I installed release 0.6.0 and it is still not working ideally. glide rebuild looks in the ./vendor folder now but places the compiled files in the wrong location.

I run glide rebuild

It puts the .a files in:

$GOPATH/pkg/darwin_amd64/github.com/nii236/project1/vendor/github.com/UserName/Repo

As opposed to

$GOPATH/pkg/darwin_amd64/github.com/UserName/Repo

This means my import statements in my code needs to look like this:

import github.com/nii236/project1/vendor/github.com/UserName/Repo

The above is the ideal path, and is preferred as that means Gocode autocompletion will work in the editor.

@mattfarina
Copy link
Member

@nii236 You are right that the location for the .a files is important. When the GO15VENDOREXPERIMENT is enabled the go tool looks in the vendor/ folder, then the $GOPATH, and finally the $GOROOT for a package. Is your install not finding the .a files in the vendor/ folder?

With the vendor/ folder multiple dependencies can also have share a dependency but have different versions. For example,

- test
  |- main.go
  |- vendor/
     |- foo
     |- bar
        |- vendor/
           |- foo

In this case both foo packages exist and can be different versions. The versions here could be different from the versions in the $GOPATH, too. The .a files need to be able to account for all these differences.

The go tool is "supposed" to be smart enough to get the right version from the right place without you needing to use an import path like import github.com/nii236/project1/vendor/github.com/UserName/Repo. In the above example main.go importing of foo would get it from inside the vendor/ folder without vendor/ needing to be in the import statement.

If retrieving the appropriate .a files isn't happening from the vendor/ folder in the same way there is a bug somewhere. Possibly in the go tool itself.

The go build command tries to detect when a package is in the vendor/ folder and use the appropriate version.

Does Gocode autocompletion work for the vendor/ folder, yet?

@nii236
Copy link
Author

nii236 commented Sep 17, 2015

@mattfarina Actually go build and go run commands work fine. The issue here is compatibility with Gocode's autocomplete. Without autocomplete it makes development much more difficult.

Running glide rebuild results in the .a files appearing in

$GOPATH/pkg/darwin_amd64/github.com/nii236/project1/vendor/github.com/UserName/Repo

I want them to appear in

$GOPATH/pkg/darwin_amd64/github.com/UserName/Repo

The .a files do not appear in the vendor folder as only the source code is there. Even if they were there, that would not be suitable for my purposes as gocode will not support it.

I participated in a discussion about it here, where the maintainer of gocode does not want to implement the GO15VENDOREXPERIMENT feature. In that case, I wish for glide to be as compatible as possible with tools that do not support GO15VENDOREXPERIMENT.

I'd like glide rebuild to build everything in /vendor and then place all the .a files in

$GOPATH/pkg/darwin_amd64/github.com/UserName/Repo

That way all legacy tools will still work!

TLDR; Basically all go tools work. I can build, run, install. The exception is gocode, which does not support vendoring and bases its autocomplete on all .a files in the pkg folder.

@nii236
Copy link
Author

nii236 commented Sep 19, 2015

I noticed your comment in the referenced conversation. Should this issue be reopened so that Glide plays well with Gocode, or should I wait for Go 1.6 to come out (6 months?)?

@stephendolan
Copy link

For any who find this thread in the future trying to figure out how to get glide rebuild to work, go 1.6 and onwards supports the vendor directory.

Instead of running glide rebuild:

go install github.com/[user]/[package] will attempt to install the package from the vendor directory if your project has one, and should put the .a files in your $GOPATH/pkg/[env]/github.com/[user]/[package] directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants