[TIP] including (or not) tests within your package
olemis at gmail.com
Thu Jul 29 11:23:40 PDT 2010
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
... more precisely of stdlib ... compiler and so on would be the same ...
> then you
> * 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?
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?
..  Debugging tutorial - Testing plan
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Dibujando figuras geométricas con Eukleides y LATEX -
More information about the testing-in-python