When a user defines a go_library or go_binary rule and all of the sources end in _test.go the gopackagesdriver includes no packages in the response. The response includes all packages for all of the dependencies of those targets but not the primary target.
This produces issues when tools attempt to locate the package that the file belongs to.
For example, when calling a linter on the file with the gopackagesdriver set, the linter reports that the file does not match any packages:
testifylint: path/to/file/sample_test.go matched no packages
The current implementation filters out _test.go files for all rules except go_test and go_benchmark. I think that this is the right approach for go_module and go_stdlib, but not for go_library and go_binary. The implementation should return a valid package for all sources that are inputs to any buildable go_library and go_binary rules.
go_module and go_stdlib don't suffer from the same problem because their sources are external, and therefore can not be targeted by the package driver (they are also much more likely to adhere to the standard usage of the _test.go suffix as they are built outside of please).
When a user defines a
go_libraryorgo_binaryrule and all of the sources end in_test.gothe gopackagesdriver includes no packages in the response. The response includes all packages for all of the dependencies of those targets but not the primary target.This produces issues when tools attempt to locate the package that the file belongs to.
For example, when calling a linter on the file with the gopackagesdriver set, the linter reports that the file does not match any packages:
The current implementation filters out
_test.gofiles for all rules exceptgo_testandgo_benchmark. I think that this is the right approach forgo_moduleandgo_stdlib, but not forgo_libraryandgo_binary. The implementation should return a valid package for all sources that are inputs to any buildablego_libraryandgo_binaryrules.go_moduleandgo_stdlibdon't suffer from the same problem because their sources are external, and therefore can not be targeted by the package driver (they are also much more likely to adhere to the standard usage of the_test.gosuffix as they are built outside of please).