Vim-go: GoRename "can't find package"

[markbates]

When trying to use GoRename from vim-go I consistently get the following error:

vim-go: Error: can't find package containing <$GOPATH>/github.com/myapp/mypackage/myfile.go.

On the command line gorename works just fine like this:

gorename -from '"github.com/myapp/mypackages".MyThing' -to MyOtherThing

But with vim-go I keep getting the above error saying it can't find the package, which is actually the current file I'm on.

I'm sure there's some fairly simple setting, ENV variable, etc... that just needs tweaking, but I can't seem to figure it out.

Thanks.

[gcmt]

I had the same issue with MacVim. You probably have the right $GOPATH set when you are on the command line but MacVim does not read your .zshrc or .bashrc, or whatever, so you won't have that variable available inside Vim. You can solve this by simply setting the $GOPATH variable in your .virmc too (at least this is how I solved):

let $GOPATH = "/your/go/path"

[markbates]

Thanks for the tip, sadly it didn't work for me. :( I'm still getting the same error.

[gcmt]

I've said half the truth. Try to put the following lines in your .vimrc and see what happens:

let $PATH = "/gorename/path:".$PATH
let $GOPATH = "/your/go/path"

[markbates]

Here's what I have in my .vimrc:

let $PATH = "/Users/markbates/development/gocode/bin/gorename:".$PATH
let $GOPATH = "/Users/markbates/development/gocode"

Still getting the same error. Also tried the following:

let $PATH = "/Users/markbates/development/gocode/bin:".$PATH
let $GOPATH = "/Users/markbates/development/gocode"

I really appreciate the help, so any other suggestions you have are definitely welcome.

[gcmt]

Here what works for me. I have exactly the following lines in my .vimrc

let $GOPATH = $HOME."/cloud/dev/go"  " required only for MacVim
let $PATH = $HOME."/opt/go/bin:".$PATH  " this is where I store go tools

" or... (works anyways)

let $GOPATH = $HOME."/cloud/dev/go"
let g:go_bin_path = $HOME."/opt/go/bin"

Then, executing :GoRename from $GOPATH/src/myapp/mypackage/file.go works as expected.

I'm on OSX with vim 7.4 installed with homebrew. :GoRename works with both Vim and MacVim (although the latter requires me to set the $GOPATH variable in my .vimrc)

I really can't help more than that. I hope you'll figure this out.

[markbates]

Still didn't work. :(

Thanks for the all the help. Eventually I'll figure out what VIM is looking for to make this work.

[fatih]

The command you use in CLI is different what vim-go uses as integration. vim-go uses the offset mode and there is no -from flag. So to debug it can you please echo the command prior to execution and run it in your terminal? All you need is to put this line :

    echo 'cmd: '. cmd

just below this line:

    let cmd = printf('%s -offset %s:#%d -to %s',  bin_path, shellescape(fname), pos, to)

inside vim-go/autoload/rename.vim , line 24. Also can you output the command here. I wonder what's happening here.

[markbates]

Putting the echo in didn't help, because it would disappear immediately when the error was printed. Instead I dumped it to the bottom of the buffer.

Here's what I get:

gorename -offset 'columns.go':#815 -to foo

[fatih]

What does it give once you execute it in the same dir ? gorename should be able to figure it out automatically. Because the cmd output seems to be correct.

[markbates]

I'm not sure what you mean by the "same dir". Could you please clarify? Thanks.

[fatih]

Sorry, I was asking to execute the command in the directory it exists. So say foo/columns.go you should execute it inside foo.

[markbates]

My $GOPATH is:

/Users/markbates/development/gocode

I'm launching VIM from this directory:

/Users/markbates/Dropbox/development/gocode/src/github.com/markbates/soda

The file, columns.go, is also in that same directory.

The error I get is:

vim-go: Error: can't find package containing /Users/markbates/Dropbox/development/gocode/src/github.com/markbates/soda

I feel like I'm running it from the right places in the right directories.

[fatih]

This might be a gorename problem. For example I've just go get the structs package:

go get github.com/fatih/structs

and done the following:

structs git:master ❯ gorename -offset 'structs.go':#479 -to raw
gorename: the old and new names are the same: raw
structs git:master ❯ gorename -offset 'structs.go':#479 -to raws
Renamed 2 occurrences in 1 file in 1 package.
structs git:master ❯ gorename -offset 'structs.go':#479 -to raw
Renamed 2 occurrences in 1 file in 1 package.
structs git:master ❯ gorename -offset 'structs.go':#479 -to raw
gorename: the old and new names are the same: raw
structs git:master ❯ echo $GOPATH
/Users/fatih/Code/go
structs git:master ❯ pwd
/Users/fatih/Code/go/src/github.com/fatih/structs

Could you do the same with this package? If this works for you, than it means gorename has a bug and cant' deal with your package. Or vice versa, if your have an example package and code that is compiling, and where gorename is not working I can try to debug it.

[markbates]

pwd:

/Users/markbates/development/gocode/src/github.com/fatih/structs

$GOPATH:

/Users/markbates/development/gocode

gorename -offset 'structs.go':#479 -to raw
Error: can't find package containing /Users/markbates/Dropbox/development/gocode/src/github.com/fatih/structs/structs.go.

Same type of error. :(

[markbates]

Thanks so much for the help, btw.

[fatih]

I think your binary is old. Can you please update it with :GoUpdateBinaries (or by hand) ? If this still doesn't solve your problem, I'm going to post this to Alan Donovan (offical Golang developer) or #go-nuts so he/people can look at it.

[markbates]

Updating the binaries didn't resolve the issue either. Sorry.

I appreciate all your help.

[alexaandru]

Your package is not under $GOPATH, so the error means exactly what it says: "can't find package".

You have GOPATH set to:

/Users/markbates/development/gocode

and work under

/Users/markbates/Dropbox/development/gocode/...

Once you'll get the two in sync, that should fix it.

[campadrenalin]

I'm having a special case of this issue, which is probably worth noting. In my case, the files are at ~/devel/some_product, and are symlinked to ~/go/src/company_name/some_product, where my $GOPATH is obviously $HOME/go.

Most tools are not confused by this - they follow symlinks in an easygoing and naive fashion. But even when I cd $GOPATH/src/company_name/some_product && vim foo.go, I still get the same error when trying to use gorename:

vim-go: gorename: can't find package containing /home/username/devel/some_product/foo.go

It's only somewhat frustrating, since I've never really tried gorename before, so I have no sensation of "that awesome thing I use all the time has broken, burn @fatih at the stake". But even so, this was something I was hoping to show off to my coworkers to help ease them into adopting Go with cool features, so if we could get a resolution, that would be brilliant.

[markbates]

This was the exact problem I was having. The solution, unfortunately is not to use symlinks if you want to use GoRename. :(

[campadrenalin]

@markbates I can only accept that as a temporary workaround. Symlinks are pretty much ideal for my scenario. Now that we've got a narrower definition of the problem, hopefully fixing gorename won't be too much ask for. If I find some free time tomorrow, I'll take a dig around the source.

[fatih]

@campadrenalin @markbates I didn't know you had the symlink problem. Could you try this branch:

https://github.com/fatih/vim-go/tree/gorename-fix

I've pushed a simple fix to resolve to the correct path, so I wonder how it works out for you guys.

[campadrenalin]

@fatih It's a good thought, but unfortunately, the problem is the other way round.

As far as I can tell, gorename is already doing its own symlink resolution. The thing is that the "real" copies of these files are all outside my $GOPATH. They are symlinked _into_ my workspace, rather than symlinked out of it. So when the filename is resolved, it's something like /home/username/devel/product_name/foo.go, which doesn't match my workspace path, /home/username/go/src/.

It's a really tricky problem. Last night I tracked it down to http://godoc.org/golang.org/x/tools/go/buildutil#ContainingPackage, but I'm not sure how to fix it, especially since it's got some cross-platform edge cases covered without tests (so any radical reimplementation would need to write tests before any real change could happen).

[fatih]

@campadrenalin did you try to contact Alan Donovan on this? He is very active in golang-nuts mailing list and tries to help with that kind of stuff. You can also link him to this issue for more info.

[campadrenalin]

Haven't done that yet, but it's a good idea.

I'm probably going to look into reversing the symlink direction (having the
real copies in my GOPATH), or switching to hard links. My current approach
doesn't just confuse gorename, it confuses a lot of tools, including go
cover. So I think it's probably time for me to stop swimming against the
current.
On Dec 29, 2014 12:32 AM, "Fatih Arslan" [email protected] wrote:

@campadrenalin https://github.com/campadrenalin did you try to contact
Alan Donovan on this? He is very active in golang-nuts mailing list and
tries to help with that kind of stuff. You can also link him to this issue
for more info.

—
Reply to this email directly or view it on GitHub
https://github.com/fatih/vim-go/issues/221#issuecomment-68240051.

[termie]

weighing in on this as I've run into the same issue, we have a setup very similar to coreos/etcd:

https://github.com/coreos/etcd/blob/master/build

As evidenced there, their usual workflow uses a symlink to put their library in the correct directory while allowing them develop from a more usable root. I agree a bit with @campadrenalin that there are a variety of go tools that do not support symlinks for this, but the go build tool itself certainly seems to and it seems like it would have the final say in the matter.

[termie]

(again, the gorename tool on the commandline works)

[termie]

digging around a bit, it seems the issue has to do with gorename trying to guess the package identifier and failing, when run on the command-line we're specifying the package identifier in the -from field, but in the text editor version of the command (-offset) it tries to guess it from the file and fails to deal with the symlink even if you cd into the symlink such that pwd shows a path under GOPATH

[termie]

just to see whether gorename would do the right thing if given a full path to the symlink directory, I tried changing autoload/go/rename.vim to use pwd -L (as it seems Vim won't give you the logical path: http://stackoverflow.com/questions/708700/getting-the-logical-path-in-vim-when-theres-a-symlink )

22: let fname = printf('%s/%s', substitute(system('pwd -L'), '\n$', '', ''), expand('%:t'))

and that works if I run it from the package under the gopath (it passes the entire logical dir to gorename which short-circuits gorename's own path resolution based on buildutil.ContainingPackage), but there is no clear way to get my package dir from the root.

there is some precedence of people using a .godir file, I think this started with heroku but a variety of other projects have supported it at some point, though the movement is towards using Godep instead (not sure how they overlap yet). The CoreOS etcd project linked above still has that file as do many others, but I feel like using it is a bit of a hack.

This sort of thing is a bit of a continual annoyance in golang, unfortunately, it seems clear that many, many projects are trying to develop in what they think is a normal way and being bitten by golang's desire for them to live three subdirectories deep.

[jeffling]

I've been having this problem too. Is there any solution?

[hraban]

Had this problem, solved it by using symlinks.

My GOPATH = /home/hraban/go3d

my package named foo was in /home/hraban/foo/gosrc

cd ~/go3d/src/
ln -s ~/foo/gosrc/ foo
cd foo
vim *.go

From there I can use :GoRename.

(I didn't read the entire thread sorry if this was obvious)

[jeffling]

I fixed my issue. Since I installed go through homebrew, the GOROOT was GOROOT="/usr/local/Cellar/go/1.4.1/libexec". Setting it in vim fixed it.

[yanpozka]

Hello, I am having the same problem and I just have a little file with package main. Any solution ??

[jeffling]

@yanpozka looks like there are a lot of different reasons this problem might prop up and a lot of solutions as well. What are the specifics of your problem?

[yanpozka]

Hi, thanks for answer @jeffling . Well I just have a simple file with package main and I am trying to use :GoRename, this is my go env output:
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/yan/.golangcode"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

[hraban]

where's the code?

[yanpozka]

my code is in: /home/yan/example/main.go

[hraban]

put it under $GOPATH/src

[yanpozka]

So for every project/package that I'll create I have to create a link under $GOPATH/src ?? Hmm :(
Thanks for your help !!

[hraban]

No comment :P

[termie]

a link under GOPATH won't just work either, you have to literally be sitting in your package under the GOPATH for the tool to figure out who you are

[yanpozka]

I don't like the idea of create a link for every project/package that I'll use

[termie]

@yanpozka most people don't, it's a go-ism that is very unfriendly to new users, you can mostly get around this stuff with tools like godeps and glide (we use glide currently), it re-writes your GOPATH and puts your dependencies in a _vendor dir, unfortunately the tools underlying gorename don't really understand that a whole lot better either

[termie]

i've been pushing for something like a .gopath or whatever file that will say "interpret this directory as existing at X path" i.e. github.com/yanpozka/myproject, but the language developers are a somewhat surly bunch

[hraban]

@termie a link under GOPATH will work, as long as your cwd is through that link and not the original dir.

[termie]

@hraban right, the point is that people tend to not want to work a bunch of directories deep unless they are a) java developers or b) work at google

[hraban]

@termie: Sorry I guess I still don't understand. My reply was to this:

a link under GOPATH won't just work either, you have to literally be sitting in your package under the GOPATH for the tool to figure out who you are

What I'm trying to say is: a link under GOPATH does work. You don't have to move the contents of your package under GOPATH---just a symlink.

But perhaps that's what you meant?

[fatih]

I've just learned that Vim doesn't follow the symlinks by default. If you start it with vim -u NONE symlinkedFile.go, you'll see it.

I've changed now the file name to resolve to full path, which causes GoRename to bypass resolving at all too (according to @termie).

So the problem is still not solved, because Vim is following the symlinks. However once we find why it follows and disallow vim following it at all, we are good to go. Either something in vim-go is causing it or one of the well known vim plugins is causing it (side effects).

I'm going to create a minimal Vim environment, without a single vimrc setting and only vim-go. If I find something I'll let you know.

[fatih]

Tried again and now it shows the symlinked file. So confused now. I think I need to dig in more deeper.

[fatih]

I'll close this as this issue is just an dead end with no solutions and it's a very special case (files being outside of GOPATH but a symlink to GOPATH). I don't have any specific answer nor do I know how to solve it in near term. We didn't had any reply to this issue for ~1 year, which seems like everyone found a way of fixing/changing their workflow. Thanks for all the comments. As always please open an issue for specific questions or needs. Thanks!

[ashb]

Is it worth tidying up the error message? package "-1" is sort of confusing at least.

[fatih]

@ashb of course, mind opening an issue on when it appears package -1? I'll fix it.

[ashb]

My vim-go was previously ~9 months out of date -- I can't reproduce this one anymore. :+1:

[akyoto]

Ran into the same issue and my real projects are under ~/projects while the tree structure GOPATH (which I absolutely do not want to work with) is in ~/workspace/ with symlinks to the real projects.

"Can't find package containing ..."

[ifraixedes]

I got this issue having a GOPATH with several directories, e.g. GOPATH=/home/x/workspace/go/src:home/x/go/src

I wanted to just report it, no idea if this can help you with anything.

[miguelmota]

Running :GoInstallBinaries and adding the following to ~/.vimrc fixed the "can't find package containing" error for me

let g:go_bin_path = "/usr/local/bin/go"
let $GOPATH = $HOME."/go"

[wsc1]

This is happening for me again after a fresh install of everything :(

[Duologic]

Sorry for bumping this issue, this is a top search result on DuckDuckGo, so adding a quick ref to the solution: https://github.com/fatih/vim-go/issues/2366#issuecomment-583033166:

let g:go_rename_command = 'gopls'