On 6 October 2015 at 14:51, David Cournapeau <courn...@gmail.com> wrote: >> Of course, the same argument can be made for installing tests, since it's >> not >> very common. > > > So we can actually get some data here :) > > At Enthought, we support around 400 packages. More than half of them are > python packages, and we can make the reasonable assumption than the vast > majority of those packages are fairly popular. > > More precisely, if I install all our supported packages on Linux: > - I count ~ 308 packages by making the assumption that one directory in > site-packages is a package (wrong but decent approximation) > - I count as `with tests` a package with at least one directory called test > in say package > > With those assumptions, I count 46 % packages with tests installed. So it is > not "not very common". Granted, we are biased toward scientific packages > which to include tests in the package, but we also package popular > web/etc... packages.
Interesting. Prompted by this, I did a check on my Python 3.4 installation. 84 packages, of which 21 have a "tests" subdirectory containing __init__.py and 4 have a "test" subdirectory containing __init__.py. That's 25%, which is certainly higher than I would have guessed. Of course, the implication is that 75% (or 54% in David's case) use test suites *not* installed with the package :-) But I think it's fair to say that installing the tests with the package is a common enough model, and it clearly does have some benefits. To answer the OP's question, I stand by my original impression, which is that "it depends" :-) I don't want the sample project to *not* include tests, so as far as that is concerned, I'm going with "the status quo wins there" and suggesting there's no reason to change. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig