Closed rantibi closed 8 years ago
Random packages should not be printing to stdout at init time. Log messages should be going to stderr anyway, but it's still obnoxious for packages to spam a program's output streams like that.
Fix your code and it should work.
Well thats mean that if I use some third party (which I can't change) that write to stdout I can't use mockgen?
I guess so, yes. Such code would not be suitable in lots of circumstances.
why not add some support for that? (I can do it and open PR for that)
Thats mean I will print some result mark line before this line
something like this fmt.Println('\nPKG_RESULT')
then here I will read from then stdout until I find this mark line, and only then try to do the decoding.
what do you say?
(If not... I will have to fork it, which is something that really don't want to do)
Sorry, it's something that just isn't worth trying to work around. Libraries shouldn't be writing to stdout. File a bug against the library that's doing it.
I run the following command :
mockgen matching BannedDA
since it used reflect mode, it generate reflectProgram witch write the pkg to os.stdout, and then the mockgen try to read the resuld and decode it.since I have init() method that print to std (using logrus logger) in part of my files, the stdout is not clean, and therefor the pkg can't be decoded in the following line, and the mockgen failed
I try to debug, and found that is
{"BannedDA", reflect.TypeOf((*pkg_.BannedDA)(nil)).Elem()}
cause the init() call.The point is the we can't trust stdout, and assume that it contains only the encode pkg,