On 19 January 2018 at 17:08, Stefan Krah <ste...@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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
