scop

For the majority of users, test code is just waste of space and bandwidth. For example, for Home Assistant, in the full dependency set `du -hc **/tests **/test` reports 82M here (2020-10-24). Granted, most users don't install the full dependency set, so they are affected to a lesser extent, and that's a smallish fraction of the total dep set size, but still. 

Proponents of test code inclusion may say it's good to have it around as a usage example. But test code is often not good code to be used as a general use example. It is often entangled with mockery, accesses things that should not be accessed in normal use to begin with, or accesses things in a way that is not supposed to be done outside of tests, etc, or all of that.

Test code can have dependencies that are not the package's runtime dependencies. When these dependencies are not installed along with the package and its real runtime dependencies (hopefully at least these are always excluded!), users must take measures to install them before they are ab

scop

Why not install tests?

For the majority of users, test code is just waste of space and bandwidth. For example, for Home Assistant, in the full dependency set du -hc **/tests **/test reports 82M here (2020-10-24). Granted, most users don't install the full dependency set, so they are affected to a lesser extent, and that's a smallish fraction of the total dep set size, but still.

But isn't it good to install test code so it's around as a usage example? Test code is often not good code to be used as a general use example. It is often entangled with mockery, accesses things that should not be accessed in normal use to begin with, or accesses things in a way that is not supposed to be done outside of tests, etc, or all of that.

Isn't it good to be able to run tests suites on installed setups e.g. when diagnosing problems? Yes, that would be nice. But a bunch of things makes this less practical as it would seem on the surface.

• Test code can have dependencies that are not