Drop buildout from ZTK packages about zopetoolkit HOT 5 CLOSED

If only zope.testrunner had a configuration file (or section in setup.cfg) so we wouldn't have to keep repeating --test-path=src everywhere... Then we could have all four build systems (tox, travis, appveyor, buildout) use zope.testrunner and rely on the [tests] extra to avoid redundancies.

from zopetoolkit.

I'm -0.5 for this. While I much prefer tox to verify that the code still works, I like bin/test -t foo for interactive debugging & fixing of failing tests.

Yes, I could use tox -e pyXX --develop and then .tox/pyXX/bin/zope-testrunner --test-path=src -t foo, but you can see how unwieldy that gets.

from zopetoolkit.

@mgedmin You should be able to write bin/tox -e pyXX -- -t foo for interactive debugging of a single test.

from zopetoolkit.

If only zope.testrunner had a configuration file (or section in setup.cfg) so we wouldn't have to keep repeating --test-path=src

I'm sure you're aware of this, but for interactive usage, I find a shell alias works well: alias ztest='zope-testrunner --test-path=src' other-options-I-use. It still works with -t xxx and so forth.

Overall, I'd say I'm +0: I personally like the idea just because I never use any of the supplied buildouts and worry they'll cause confusion. I always start from a virtualenv per-project when making substantial changes, or just rely on a global installation of detox when making small changes. (I have a .dir-locals.el in the top-level of each ZTK checkout to be sure my editor and its linter are automatically in the right virtualenv when editing any files.)

But most of the buildout.cfg are small, and so long as they don't contain any version pins or otherwise actively contradict tox.ini and .travis.yml they don't seem to cause enough harm to justify taking them away from those that do use them.

from zopetoolkit.

Okay, then we'll leave it as it is.

from zopetoolkit.