<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 1:57 PM, Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On October 6, 2015 at 8:51:30 AM, Antoine Pitrou (<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>) wrote:<br>
> On Tue, 6 Oct 2015 15:34:38 +0300<br>
</span><span class="">> Ionel Cristian Mărieș wrote:<br>
> ><br>
> > Very few<br>
> > test runners change the current working directory by default [1], so it's<br>
> > better to just get a better project layout. pyca/cryptography<br>
</span><span class="">> > is a good example.<br>
><br>
> The "src" convention is actually terrible when working with Python<br>
> code, since suddenly you can't experiment easily on a VCS checkout, you<br>
> have to do extra steps and/or write helper scripts for it.<br>
<br>
</span>Without doing it, you have very little assurances you’re actually testing<br>
against the installed project and not the project that's sitting in curdir.<br>
This is why pyca/cryptography does it, attempting to run the copy in . won't<br>
do anything but raise an exception since the .so won't be built.<br>
<br>
It doesn't really make experimenting in a VCS any harder, since all you need to<br>
do first is run ``pip install -e .`` and it will do a development install and<br>
add the src/ directory to sys.path.<br>
<span class=""><br>
><br>
> The fact that few Python projects, including amongst the most popular<br>
> projects, use that convention mean it's really not considered a good<br>
> practice, nor convenient.<br>
><br>
><br>
<br>
</span>Of course, the same argument can be made for installing tests, since it's not<br>
very common.<br></blockquote><div><br></div><div>So we can actually get some data here :)<br><br>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.<br><br>More precisely, if I install all our supported packages on Linux:<br> - I count ~ 308 packages by making the assumption that one directory in site-packages is a package (wrong but decent approximation)<br> - I count as `with tests` a package with at least one directory called test in say package<br><br>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.<br><br>David<br></div></div></div></div>