<p>On Jul 26, 2010 8:19 PM, &quot;Alfredo Deza&quot; &lt;<a href="mailto:alfredodeza@gmail.com" target="_blank">alfredodeza@gmail.com</a>&gt; wrote:</p><p>&gt; A few weeks ago in our local Python meeting someone mentioned what a drag<br>

&gt; was to (most of the time) have to download<br>&gt; the source for a package they have just installed to run the tests because<br>&gt; the &#39;test(s)&#39; directory was not included at the time<br>&gt; of installation.<br>

&gt; <br>&gt; Some packages include them (like unittest2) and some (most?) don&#39;t.<br>&gt; <br>&gt; What do you guys feel about including the test directory within your package<br>&gt; so it is included at the time of installation?<br>

&gt; <br>&gt; I&#39;m gearing towards including them, but wanted to hear your opinion about<br>&gt; it.<br></p><p>Speaking from my experience from framework development the general consensus is that test-in-packages make things more complicated, as complex packages tend to have additional test dependencies and sometimes you need a special setup for some of them and tests just bloat the userspace if they are distributed together. </p>
<p>Personally other than running on other platforms/setups the core team lacks I don&#39;t see any benefit from having the tests in package. At worst of any of those tests fails under some obscure situation they should be catch by the build/release process.</p>
<p>And if you as an end user are submitting a patch and want to run the test, I expect you to have a fork or checkout, instead of a plain old patch which means you are downloding the whole thing anyway.</p><p>My 0.02cents</p>
<p></p>