[TIP] including (or not) tests within your package

[Olemis Lang]

On Tue, Jul 27, 2010 at 8:13 PM, Andrew Bennetts <andrew at bemusement.org> wrote:
> Ben Finney wrote:
>> Marius Gedminas <marius at gedmin.as> writes:
>>
>> > Other than wasting a bit of disk space, what are the downsides of
>> > installing the tests [along with the rest of the package]?
>>
>> They would thereby become part of the *public* interface for the
>> package. I don't want that implied promise; the test suite is subject to
>> arbitrary unannounced change or removal.
>

Even if Ben and I , we both support the same idea , IMO this is not
exactly the main reason I take into account . IMO it's all about the
purpose and about being minimalistic . IMO bdist_* packages are for
use in production systems. I wouldn't like to see anybody messing
around and running tests in a production system , and if this is what
users want to do, I prefer to force them to install a separate test
package and make that decision explicit . OTOH sdist packages are the
ideal target for research and ...

> Surely you don't consider every importable name to be part of the public
> interface for a package?
>

+1 , besides I suppose it'd be quite unlikely that somebody will use
your test code for building it's own app (at least I don't advocate
this) . The only exception is in cases when a framework provides test
infrastructure or shortcuts (e.g. Trac provides test classes
ready-to-use by plugins, and that would be some sort of API to write
for test code ...)

>> They're for use while developing (hence part of the source), not in their
>> deployed location (hence *not* part of the binary package).
>
> What about packages that build on your packages?  e.g. it's common for
> tests for bzr plugins to use some test infrastructure from bzrlib.tests
> in their own test suite.  Ditto for applications (or libraries) built on
> Twisted.
>

Ahhh !!! Similar to the previous example about Trac plugins ...

This is a real issue . In my approach I'd solve that this way ...

  - As I mentioned before there'd be a single sdist pkg
    (e.g. foo) and two bdist_* packages (e.g. foo for `install`
    and foo_tests for `test`)
  - Pkg bar includes foo in `install_requires` and foo_tests
    in `tests_require`
  - Voilà !

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article: