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

[Olemis Lang]

On Thu, Jul 29, 2010 at 11:50 AM, Alfredo Deza <alfredodeza at gmail.com> wrote:
> On Thu, Jul 29, 2010 at 12:04 PM, Olemis Lang <olemis at gmail.com> wrote:
>> On Thu, Jul 29, 2010 at 10:07 AM, Barry Warsaw <barry at python.org> wrote:
>> > On Jul 28, 2010, at 07:49 AM, Olemis Lang wrote:
>> >
>> >>>> +1 for including the tests by default.
>> >>>
>> >>> Agreed 100x with Barry -
>> >>
>> >>IMO, tests shouldn't be installed in production systems ...
>> >
>> > It's certainly within the decisions of platform packagers to separate
>> > tests
>> > from the code, but I'd argue that it's not worth it.  I just don't see
>> > what
>> > advantage *not* including the tests gives you.
>>
>>  - Nobody (human, software, ...) is gonna execute *accidentally* the tests
>>    in a production server (e.g. running server will not wait until
>> finishing the
>>    3h test run to acquire global lock or connection ...)
>>  - Space is preserved . That's something important if talking about
>>    using the package in constrained environments (e.g. limited devices,
>>    shared hosting, ...) . This also makes me recall decisions like
>>    splitting stdlib in order to build custom (as small as possible,
>>    yet functional) installers for Python itself
>
> If you are trying to split the stdlib to build a custom installer for
> Python,

... more precisely of stdlib ... compiler and so on would be the same ...

> then you
> are:
> * already going through massive amounts of work which doesn't compare to
> removing tests from a package

IMO that's mainly due to the fact that the root cause seems to be
historical &| organizational. For instance, unittest2 and other recent
modules have been implemented & distributed separately to be
backported and used in previous versions of Python. If stdlib
development would be carried out by preserving the separation between
packages (which is not a completely & absolutely crazy idea,
everything in PyPI is developed this way ;o) then everything would
have been much easier right now (and test & test_support & ... are
packages as well, and removing them makes no harm since Windows
installer allows to do that ;o).

There's another option I suggested in a message to python-dev , which
is to write a single parameterized setup.py script ... and leave
stdlib just like it is nowadays ...

... well this is OT , so ...

> * in a very unique case (e.g. this is not a common situation)

Such arrangement allows many other useful scenarios , e.g. like
setting up hybrid systems (like Debian apt hybrid systems) using
recent versions of some Py modules in old installations and viceversa
...

> Personally, I would not care to support the idea of removing my tests from
> my package
> just to be able to fit in that situation.

Considering the difference I made about what I consider a production
scenario and dev environment, I don't support the idea of having
executable test code & test deps in *production environments* ... just
without a good reason (specially if there's a way to have it there at
any time if I find a good reason ;o).

> If you are trying to run a python package in a restricted device, why
> wouldn't you want to run some tests?

[1]_

once ? ok . always ??? not sure ;o)

I'm not aware, Nokia S60 python implementation distributes test suites
(stdlib ?) in the installation included in their phones ?

> And if the tests don't fit in the device... why would you want to use it to
> start with?

[1]_

.. [1] Debugging tutorial - Testing plan
        (http://wiki.opensource.nokia.com/projects/Debugging_tutorial#Testing_plan)

-- 
Regards,

Olemis.

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

Featured article:
Dibujando figuras geométricas con Eukleides y LATEX -
http://feedproxy.google.com/~r/simelo-es/~3/o7jBqp97elc/dibujando-figuras-geometricas-con.html