Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not install non production code by default #16

Open
nim-nim opened this issue Mar 4, 2018 · 0 comments
Open

Do not install non production code by default #16

nim-nim opened this issue Mar 4, 2018 · 0 comments

Comments

@nim-nim
Copy link

nim-nim commented Mar 4, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant