<div dir="ltr">[Splitting into a separate thread]<br><div class="gmail_quote"><div dir="ltr"><div><div><div><div><br></div>Do we really need to overthink something that requires a trivial alias to set up for one's own convenience?<br>

<br></div>Picking a Python version (as Barry mentions) is just one of the problems. What's wrong with:<br>
<br></div>alias rupytests='python3 -m unittest discover"<br>alias runpytests2='python2 -m unittest discover"<br><br>?<br><br></div><div>Don't get me wrong, I love the "discover" option and agree that it should be the recommended way to go - but isn't this largely a documentation issue?<br>


</div><div><br></div>Eli<br><br><div><br><div><div><div><div><div class="gmail_extra"><br><br><br><br><div class="gmail_quote">On Mon, Mar 4, 2013 at 11:14 AM, Barry Warsaw <span dir="ltr"><<a href="mailto:barry@python.org" target="_blank">barry@python.org</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:<br>
<br>
>> $ python -m unittest discover<br>
>> $ python setup.py test<br>
>> $ python setup.py nosetests<br>
>> $ python -m nose test<br>
>> $ nosetests-X.Y<br>
>><br>
>> Besides having a multitude of choices, there's almost no way to<br>
>> automatically discover (e.g. by metadata inspection or some such) how to<br>
>> invoke the tests.  You're often lucky if there's a README.test and it's<br>
>> still accurate.<br>
><br>
>I hope we can have a "pytest" utility that does the right thing in 3.4 :-)<br>
>Typing "python -m unittest discover" is too cumbersome.<br>
<br>
</div>Where is this work being done (e.g. is there a PEP)?<br>
<br>
One thing to keep in mind is how to invoke this on a system with multiple<br>
versions of Python available.  For example, in Debian, a decision was recently<br>
made to drop all the nosetests-X.Y scripts from /usr/bin[1].<br>
<br>
This makes sense when you think about having at least two major versions of<br>
Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), *plus* debug<br>
versions of each.  Add to that, we don't actually know at package build time<br>
which versions of Python you might have installed on your system.<br>
<br>
A suggestion was made to provide a main entry point so that `pythonX.Y -m<br>
nose` would work, which makes sense to me and was adopted by the<br>
nose-devs[2].<br>
<br>
So while a top level `pytest` command may make sense, it also might not ;).<br>
While PEP 426 has a way to declare test dependencies (a good thing), it seems<br>
to have no way to declare how to actually run the tests.<br>
<br>
Cheers,<br>
-Barry<br>
<br>
[1] Start of thread:<br>
    <a href="http://comments.gmane.org/gmane.linux.debian.devel.python/8572" target="_blank">http://comments.gmane.org/gmane.linux.debian.devel.python/8572</a><br>
<br>
[2] <a href="https://github.com/nose-devs/nose/issues/634" target="_blank">https://github.com/nose-devs/nose/issues/634</a><br>
<div><div>_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com" target="_blank">http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com</a><br>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>
</div><br></div>