Fighting goimports

[rnapier]

Not really a bug, just information.

The use of log as a global variable fights with the goimports tool, which cannot tell that it's not the log package and so adds an extra import. This is unlikely to be fixed in goimports since it basically works like gofmt.

Anyone who uses goimports as part of GoSublime, etc. will have trouble modifying spdy files. I have a work-around via an extra wrapper script that looks for "spdy" and passes those files through unchanged, but I wanted to let you know about it.

[SlyMarbo]

Thanks for the info. I'll think about this too. In my opinion, a tool modifying the code should be aware of the package context. github.com/nsf/gocode, which I use for IDE autocomplete is aware of the global variable and works fine. Although it's a very different aim, I feel goimports should do something similar.

[rnapier]

For those interested in this problem here's the script I currently use to work around it. It doesn't work with the "common" package since that was created. It looks for packages that appear to start with the name "spdy". (Far from ideal, but this problem is very hard to work around.) Note that goimports cannot be aware of all of the code because it receives the file on STDIN from Gosublime using the gofmt hook. This allows reformatting to be applied inline with saving (and allowing Gosublime to be the only one to modify the file) rather than creating a write/read/reformat/write/read on every save.

#!/usr/bin/ruby

require 'open3'

input = STDIN.read

if input.match(/^package spdy/)
  o,s = Open3.capture2("gofmt", :stdin_data=>input, binmode:true)
  if s == 0 then
    print o
  end
else
  o,s = Open3.capture2("goimports", :stdin_data=>input, binmode:true)
  if s == 0 then
    print o
  end
end