I have a package collision where I get the following error:
mockgen -package=mocks -source=myproto.pb.go -destination=mocks/my_mocks.go
imported package collision: "foo" imported twice
I see one import that is obvious:
import foo "blah/blah/foo"
But I don't know where to start tracking down the duplicate import (nor where it is coming from). It seems strange to me that this is an issue as I am importing myproto.pb.go just fine, so I'm wondering if there is really an issue w/duplicate imports. Also, GoLand isn't showing any issues.
I'm hoping someone can point me in the direction of getting more information about where the duplicate import is coming form, checking if there is some issue and/or working around the issue.
This seems to be an ongoing issue. I just ran into it with it claiming "rand" was imported twice (even though my code doesn't import "rand").
The following workaround worked for me: Write down the list of interfaces in myproto.pb.go you wish to mock, and use "reflect mode" instead of "source mode"
mockgen -package=mocks -destination=mocks/my_mocks.go path.to/package/containing/myproto/pb/go [space-separated interface names]
should be equivalent to your previous invocation:
mockgen -package=mocks -source=myproto.pb.go -destination=mocks/my_mocks.go
but for some reason is more robust and does not trigger the double-import error.
Related
previously I was using
"google.golang.org/api"=>v0.10.0
in my go.mod file and I was able to import
gensupport "google.golang.org/api/gensupport"
But with new
"google.golang.org/api"=>v0.103.0
I was unable to import gensupport and as I and my colleague have investigated, gensupport was shifted to
"google.golang.org/api/internal/gensupport"
but while using this import there is one error saying
Use of the internal package is not allowed
So now how I will be able to use gensupport with new "google.golang.org/api"=>v0.103.0 version.
Your only option is to vendor an older version of the library.
This package has been marked for internal use for a long time and was also marked to allow for breakages. See https://github.com/googleapis/google-api-go-client/issues/416 for options.
Goland (version 2021.2, on Linux) can't auto import "fmt", when add a line of code that use fmt's functions.
I need to add import "fmt" by hand.
But seems it doesn't have problem with other built-in go packages.
It that a bug, or a special design ?
BTW, the similar issue occur for 3rd-party package "github.com/stretchr/testify/assert", the auto import will hint several options to import assert, but the above one is always not in the list in my case, had to import by hand.
Screenshot:
#Update: Cause of issue & solution found
Issue:
Solution: just remove the 2 line, then import works immediately.
Thanks to s0xzwasd's comment under question, and jinseok.oh's answer, which actually mentioned the setting.
There is Global Println() function and also fmt.Println() function()
If you writh Println and press ctl+space only then IDE will set autocomplete Println().
/// add
Also you have to check this. Is there any exclucde from import and completion?
If doesn't exist, then my last advise is doing invalidate caches/ restart
I am faced with a strange issue. I recently rebuilt my Xcode project file using a tool called Xcode gen, I now have hundreds of errors in my files related to imports, for example:
import Foundation
struct BillingHistoryDetailTableCellViewModel {
let contentColor: UIColor?
// Implementation
}
error: Cannot find type 'UIColor' in scope
Why am I suddenly faced with this error now? Xcode had no issue compiling this kind of file before.
Is there some kind of setting or flag required to fix this?
Answering this for others:
If your project happens to include objective-c code and the bridge file includes imports to frameworks that use UIKit then this will be imported globally across your project, hence Xcode not asking for the import in files where you reference objects in UIKit.
This seems kinda like a bad side effect of using an objective c bridge as it's easy to miss the adding the import statements.
I was reading one of the examples in processing.py, Arctangent. It has an import statement:
from eye import Eye
I cannot figure out where this 'eye' library that I'm importing from is located. I don't see it in the processing.py reference. I searched the filesystem under the processing-3.5.4/ subdirectory and cannot find any module named eye either.
The program works. But I wonder where these modules are, and where can I find a reference for them. I'm wondering now what else is available that I cannot see.
I failed to notice that the example had a second tab with the code to be imported. These aren't standard library modules.
I'm working with ory-am / hydra and it makes me bug in the Golang library gopkg.in/gorethink/gorethink.v3, the error is as follows:
../../../gopkg.in/gorethink/gorethink.v3/cluster.go:10:2: case-insensitive import collision: "github.com/sirupsen/logrus" and "github.com/Sirupsen/ logrus "
this after adding go app.go
If you have any suggestions with which you can guide me to solve this incident
That package went through a very painful, and regretful, rename some time back. It was previously Sirupsen/logrus, and was renamed to sirupsen/logrus. The latter is erroneously considered more idiomatic by some, but Go handles mixed case imports with no problem, so the rename was unnecessary, and the author regrets it. But renaming back would just add to the confusion, so the decision was made to stick with the unnecessary lowercase version.
But that's all in the past. At this point, the lowercase version is the only working one.
The behavior you have observed is usually the result of importing two (or more) packages which depend on the logrus package, one depending on the older name, the other depending on the newer name. Therefore, if you have a dependency that still has the upper-case version as a dependency, that library needs to be updated.
From the project readme:
Case-sensitivity
The organization's name was changed to lower-case--and this will not be changed back. If you are getting import conflicts due to case sensitivity, please use the lower-case import: github.com/sirupsen/logrus.
Alternately, you could vendor an old version of the library with the capitalized import name and update all of your imports to use that version.