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

[Olemis Lang]

On Thu, Aug 12, 2010 at 7:14 AM, Olemis Lang <olemis at gmail.com> wrote:
> On Thu, Aug 12, 2010 at 4:04 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>> On Wed, Aug 11, 2010 at 12:38 AM, Ben Finney <ben+python at benfinney.id.au> wrote:
>>> Fernando Perez <fperez.net at gmail.com> writes:
>>
> [...]
>>
>> Ultimately all I can say is that I have *extensive, real-world*
>> evidence of this approach having worked *fantastically* well for
>> ipython, numpy, scipy, nipy.*, etc over the last few years.
>
> The same can be stated by people that don't include tests in packages

In fact , check out any Ubuntu | Debian repos & you'll realize many
instances for which there will be the following pkgs for a single
*app*

  - deb-src package (i.e. source package).
  - app-doc deb package (i.e. binary package to install docs).
  - app-dbg deb package (i.e. binary package to install the
    app with debug symbols).
  - app deb package (i.e. binary package to install the app).

That might be slightly different in Python because of the
characteristics of the language but the following one-to-one
relationship wouldn't be as crazy as it seems

  - deb-src package will become sdists.
  - app-doc deb package might become docs package ,
    but sometimes PyApps -e.g. *my* PyApps- are self
    documented, anyways ...
  - app-dbg deb package might become either bdist package
    installing only the test suite (which might also be a different
    pkg named app-tests or whatever ...) or the app with test suite +
    test deps + ...
  - app deb package will become the binary package installing
    *ONLY* the app , and nothing else

PS: I just noticed that pkg naming conventions when I tried to install
few minutes ago gstreamer plugins in Ubuntu Lucid , so that's a good &
real place to start the research

-- 
Regards,

Olemis.

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

Featured article: