[Python-ideas] Official site-packages/test directory

[Paul Moore]

On 19 January 2018 at 17:08, Stefan Krah <stefan at bytereef.org> wrote:
> On Fri, Jan 19, 2018 at 04:23:23PM +0000, Paul Moore wrote:
>> Another common approach is to not ship tests as part of your (runtime)
>> package at all - they are in the sdist but not the wheels nor are they
>> deployed with "setup.py install". In my experience, this is the usual
>> approach projects take if they don't have the tests in the package
>> directory. (I don't think I've *ever* seen a project try to install
>> tests except by including them in the package directory...)
>
> Yes, given the current situation not shipping is definitely the best
> approach in that case.
>
> I just thought that if we did have something like site-packages/stest
> (Guido correctly noted that "test" wouldn't work), people might use it.
>
>
> But it is all very speculative and I'm not really sure myself.

To be usable, tools like pip, wheel, setuptools, flit, etc, would all
need to be updated to take into account this option, as well as the
relevant standards (the wheel spec for one). Add to that the changes
needed to places like the sysconfig package to allow introspecting the
location of the new test directory. Would there be a test directory in
user-site as well? What about in virtual environments? (If only in
site-packages, then it'll likely be read-only in a lot of
environments). Also, would we need to reserve the directory name
chosen to prohibit 3rd party packages using it? As we've seen the
stdlib test package clashes with the original proposal, who's to say
there's nothing on PyPI that uses stest?

The idea isn't a bad one in principle - there's a proposal from some
time back on distutils-sig that Python packaging support more "target
locations" matching the POSIX style locations - for docs, config, etc.
A test directory would fit in with this idea. But it's a pretty big
change in practice, and no-one has yet done much beyond talk about it.
And the proposal would likely have put the test directory *outside*
site-packages, which avoids the name clash problem.

I'd think that the idea of a site-packages/stest directory would need
a much more compelling use case to justify it.

Paul

PS There's nothing stopping a (distribution) package FOO from
installing (Python) packages foo and foo-tests. It's not common, and
probably violates people's expectations, but it's not *illegal* (the
setuptools distribution installs pkg_resources as well as setuptools,
for a well-known example). So in theory, if people wanted this enough,
they could have implemented it right now, without needing any change
to Python or the packaging ecosystem.