alias runpytests2='python2 -m unittest discover"

?

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?
">

(original) (raw)

\[Splitting into a separate thread\]

Do we really need to overthink something that requires a trivial alias to set up for one's own convenience?


Picking a Python version (as Barry mentions) is just one of the problems. What's wrong with:


alias rupytests='python3 -m unittest discover"
alias runpytests2='python2 -m unittest discover"

?

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?


Eli






On Mon, Mar 4, 2013 at 11:14 AM, Barry Warsaw <barry@python.org> wrote:
On Mar 04, 2013, at 07:41 PM, Antoine Pitrou wrote:

\>> $ python -m unittest discover
\>> $ python setup.py test
\>> $ python setup.py nosetests
\>> $ python -m nose test
\>> $ nosetests-X.Y
\>>
\>> Besides having a multitude of choices, there's almost no way to
\>> automatically discover (e.g. by metadata inspection or some such) how to
\>> invoke the tests. �You're often lucky if there's a README.test and it's
\>> still accurate.
\>
\>I hope we can have a "pytest" utility that does the right thing in 3.4 :-)
\>Typing "python -m unittest discover" is too cumbersome.

Where is this work being done (e.g. is there a PEP)?

One thing to keep in mind is how to invoke this on a system with multiple
versions of Python available. �For example, in Debian, a decision was recently
made to drop all the nosetests-X.Y scripts from /usr/bin\[1\].

This makes sense when you think about having at least two major versions of
Python (2.x and 3.x) and maybe up to four (2.6, 2.7, 3.2, 3.3), \*plus\* debug
versions of each. �Add to that, we don't actually know at package build time
which versions of Python you might have installed on your system.

A suggestion was made to provide a main entry point so that \`pythonX.Y -m
nose\` would work, which makes sense to me and was adopted by the
nose-devs\[2\].

So while a top level \`pytest\` command may make sense, it also might not ;).
While PEP 426 has a way to declare test dependencies (a good thing), it seems
to have no way to declare how to actually run the tests.

Cheers,
\-Barry

\[1\] Start of thread:
� � http://comments.gmane.org/gmane.linux.debian.devel.python/8572

\[2\] https://github.com/nose-devs/nose/issues/634
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com