[Distutils] Where should I put tests when packaging python modules?

[Robert Collins]

On 6 October 2015 at 23:47, Ionel Cristian Mărieș <contact at ionelmc.ro> wrote:
>
> On Tue, Oct 6, 2015 at 12:51 PM, Wes Turner <wes.turner at gmail.com> wrote:
>>
>> self-testable programs are really ideal (e.g POST power-on self test)
>> relevant recent topical discussion of e.g
>> CRC and an optional '-t' preemptive CLI parameter:
>> https://github.com/audreyr/cookiecutter-pypackage/pull/52
>
>
> I would be interesting to talk about what's worth including in a "self-test"
> feature.
>
> Most suites aren't suitable for including as whole. You don't want to
> include integration (functional) tests for sure :-)
>
> There's also the ever-unanswered question of how to deal with test
> dependencies. Some will think that it's ok to always install them, but then
> again, after seeing how `mock` depends on `pbr` - and how `pbr` just decides
> to alter your `setup.py sdist/bdist_*` output without being asked or invoked
> has made me very wary of this practice. How I have to make sure my python
> installs have certain versions of `pbr` or no `pbr` at all, every time I
> want to build a package :-(

Hangon, there's clearly a *huge* gap in understanding here.

pbr does *not* modify *anyones* setup.py output unless its enabled.

***setuptools*** enables all its plugins unconditionally (because
entrypoints, yay), and then pbr has to explicitly *opt-out* of doing
anything.

Which *we do*.

There was a bug where a new thing added didn't have this opt-out, and
its since been fixed. There's a separate related bug that the opt-out
checking code isn't quite robust enough, and thats causing some havoc,
but there's a patch up to fix it and as soon as we have a reliable
test we'll be landing it and cutting a release.

If there was a way to plug into setuptools where pbr code wasn't
called on random packages, and we didn't have to manually opt-out, why
that would be brilliant.

[Note: I'm not saying setuptools is buggy - it chose this interface,
and thats fine, but the consequence is bugs like this that we have to
fix].

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud