On 6 October 2015 at 08:51, Antoine Pitrou <[email protected]> wrote: > They should be inside the module. That way, you can check an installed > module is ok by running e.g. "python -m mypackage.tests". Any other > choice makes testing installed modules more cumbersome.
One inconvenience with this is that if you use an external testing framework like nose or pytest, you either need to make your project depend on it, or you need to document that "python -m mypackage.tests" has additional dependencies that are not installed by default. With an external tests directory, the testing framework is just another "development requirement". It's only a minor point, conceded. > The PyP"A" should definitely fix its sample project to reflect good > practices. +1 on the sample project following recommended guidelines. When I originally wrote that project, the consensus (such as it was) was in favour of tests outside the installed project. But that may have simply reflected the group of people who responded at the time. It does however have the advantage that it's consistent with how other PyPA projects like pip and virtualenv structure their tests. The big problem is that I don't think there *is* a consensus on best practice. Both options have their supporters. It would also be very easy to take the view that the PyPA sample project should omit the test directory altogether, as it's a sample for the *packaging* guide, and development processes like testing are out of scope (that's why we don't include a documentation directory, or recommend sphinx, for example). Personally, I think if we go to that extreme, the sample project becomes useless as a "real world" template, but maybe people wanting a starter project template should be directed to projects such as cookiecutter instead. Paul _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
