I see that the new code that relies on golist to list elements to install now installs test code and examples by default. And, to workaround their usual breakage, do not generate the corresponding requires
This is wrong and a bad idea on several plans:
non production code should not be installed by default
if it is installed, it should work (ie declare the needed deps)
I know a few projects import examples of other projects in their tests but this is really a marginal case and should not direct the general installation policy. And, I could workaround it via the exclusion flags, but sorting those common cases really belongs in the heart of the code analysis engine.
However, the good news is that now we started using lockfiles, it is possible to distinguish between "this package ships this go directory for tests" and "this package ships this go directory for production code" in autodeps
Therefore, I propose the following changes in golist:
golist lists neither example file nor test files by default
when passed the -s flag (for system unit test install, like we already use for checks, maybe rename it to -u), it lists only unit tests and testdata
when passed the -x flag it lists only example file
And then change the shell installation logic to:
install only production code by default
install only unit tests with -s, and create a .goipath-tests lockfile
install only example files with -x, and create a .goipath-examples lockfile
With the following autodeps logic:
in presence of a .goipath-tests call golist with -s, generate requires for tests, do not generate provides (unless you have a use for golang-test(foo) provides)
in presence of a .goipath-examples lockfile call golist with -x, generate requires for example code, generate provides for example code (for the projects that import example code)
That would allow splitting cleanly unit tests and examples in their own separate subpackages and have clean production-only -devel subpackages
I see that the new code that relies on golist to list elements to install now installs test code and examples by default. And, to workaround their usual breakage, do not generate the corresponding requires
This is wrong and a bad idea on several plans:
I know a few projects import examples of other projects in their tests but this is really a marginal case and should not direct the general installation policy. And, I could workaround it via the exclusion flags, but sorting those common cases really belongs in the heart of the code analysis engine.
However, the good news is that now we started using lockfiles, it is possible to distinguish between "this package ships this go directory for tests" and "this package ships this go directory for production code" in autodeps
Therefore, I propose the following changes in golist:
And then change the shell installation logic to:
With the following autodeps logic:
That would allow splitting cleanly unit tests and examples in their own separate subpackages and have clean production-only -devel subpackages