[Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda) (original) (raw)
Eli Bendersky eliben at gmail.com
Mon Mar 4 22:26:57 CET 2013
- Previous message: [Python-Dev] Introducing Electronic Contributor Agreements
- Next message: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[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 at 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 levelpytest
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 at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130304/98629198/attachment.html>
- Previous message: [Python-Dev] Introducing Electronic Contributor Agreements
- Next message: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]