[TIP] including (or not) tests within your package
alfredodeza at gmail.com
Thu Jul 29 09:50:13 PDT 2010
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
> > from the code, but I'd argue that it's not worth it. I just don't see
> > 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, then you
* already going through massive amounts of work which doesn't compare to
removing tests from a package
* in a very unique case (e.g. this is not a common situation)
Personally, I would not care to support the idea of removing my tests from
just to be able to fit in that situation.
And about Shared Hosting: unless you have over 500MB in tests, I do not see
this as an issue.
If you are trying to run a python package in a restricted device, why
wouldn't you want to run some tests?
And if the tests don't fit in the device... why would you want to use it to
> - Python test suite is *optionally* installed -at least in Windows-,
> isn't it ?
> So it seems it's worth it for all packages in stdlib under certain
> conditions .
> - It's always possible to install the test package at any time and do
> whatever with it , as well as remove it later.
> > And arguably it can make for
> > more complicated packaging,
> Yes definitely , but I'd say complex (since «complex is better than
> complicated» ;o)
> > Sure, there are exceptions, and big frameworks/packages might want to do
> > things differently. But I'd argue that the *majority* of Python packages
> > fairly simple and straightforward and it's better (and easier!) to just
> > include the tests.
> Well, «practicality (will always) beat purity» (and that's why I first
> mentioned that I'd like to do something like this , but currently I
> don't 'cause, in practice, I've not had the time to think about how to
> do it «perfect» & easy ;o) .
> PS: I understand that probably there's not a universal solution for
> all kind of packages .
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
> Featured article:
> Dibujando figuras geométricas con Eukleides y LATEX -
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the testing-in-python