| msg155476 - (view) |
Author: Michael Foord (michael.foord) *  |
Date: 2012-03-12 21:00 |
| "python -m unittest ..." is a pain to type. A "pyunit" script would be a nice shorthand. (unittest2 has a unit2 script that does this.) |
|
|
| msg155477 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-03-12 21:03 |
| And it should do "discover" by default, IMO (like nose does). |
|
|
| msg155479 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2012-03-12 21:05 |
| Right "unit2" on its own does discover by default now. (On head, not sure if that's released yet.) |
|
|
| msg174405 - (view) |
Author: Andrew Svetlov (asvetlov) * |
Date: 2012-11-01 12:06 |
| +1 for both pyunit script and autodiscovering by default. |
|
|
| msg174905 - (view) |
Author: Andrew Svetlov (asvetlov) * |
Date: 2012-11-05 13:08 |
| Is it should be separate binary? Or problem can be solved by regular python script with executable bit? What's about Windows? |
|
|
| msg174907 - (view) |
Author: Michael Foord (michael.foord) * |
Date: 2012-11-05 13:11 |
| A python script should be fine - this is what unittest2 does and I haven't had any requests from Windows users for a binary. |
|
|
| msg177426 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2012-12-13 17:15 |
| Yes, let’s keep the pydoc/pyvenv/etc convention for pyunit. The audience is developers, whom we expect to be able to set up their environment correctly, and the -m fallback still works. |
|
|
| msg177549 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-12-15 19:05 |
| Berker's proposed implementation looks weird to me. Why the "__unittest" variable? Also, it would be better to make unittest's API more flexible, rather than manually tweaking sys.argv to enable discovery. |
|
|
| msg177564 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2012-12-15 21:03 |
| I think the __unittest name is magic to hide modules from the unittest package in error/failure tracebacks. About the script: can’t it be as simple as runpy.run_module? |
|
|
| msg177748 - (view) |
Author: Berker Peksag (berker.peksag) * |
Date: 2012-12-19 15:47 |
| Antoine and Éric: Thank you for the reviews and suggestions. > Why the "__unittest" variable? I added the "__unittest" variable after read issue 7815 and the related changeset: http://hg.python.org/cpython/rev/2858cae540e4/ See also: - http://stackoverflow.com/questions/12583015/how-can-i-hide-my-stack-frames-in-a-testcase-subclass - https://github.com/nose-devs/nose2/pull/28/files However, without the variable tracebacks are still clear: $ pyunit -v test_acc (test_bar.TestAcc) ... ok test_acc_negative (test_bar.TestAccNegative) ... ok test_mul (test_foo.TestMul) ... ok test_mul_negative (test_foo.TestMulNegative) ... ok test_mul (test_baz.TestMul) ... FAIL ====================================================================== FAIL: test_mul (test_baz.TestMul) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/berker/hacking/cpython/test_baz.py", line 12, in test_mul self.assertEqual(3, mul(2, 2)) AssertionError: 3 != 4 ---------------------------------------------------------------------- Ran 5 tests in 0.002s FAILED (failures=1) > Also, it would be better to make unittest's API more flexible, rather > than manually tweaking sys.argv to enable discovery. You're right. Something like that? unittest.main(discover=True) > About the script: can’t it be as simple as runpy.run_module? I will try that, thanks. |
|
|
| msg183489 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2013-03-04 19:38 |
| As I mentioned on python-dev, having a `pyunit` script is nice (whatever it's called), but we need to keep the `-m invocation` which will probably be the recommendation on distros such as Debian which provide multiple versions of Python. We're not going to want to install all possible flavors of `pyunit2.6`, `pyunit2.7`, `punit2.6-dbg`, `pyunit-3.2-dbg`, etc. etc. |
|
|
| msg183491 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2013-03-04 19:45 |
| > We're not going to want to install all possible flavors of > `pyunit2.6`, `pyunit2.7`, `punit2.6-dbg`, `pyunit-3.2-dbg`, etc. etc. Why not? |
|
|
| msg183495 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2013-03-04 20:09 |
| On Mar 04, 2013, at 07:45 PM, Antoine Pitrou wrote: > >Antoine Pitrou added the comment: > >> We're not going to want to install all possible flavors of >> `pyunit2.6`, `pyunit2.7`, `punit2.6-dbg`, `pyunit-3.2-dbg`, etc. etc. > >Why not? We don't know at package build time which versions will be necessary or possible, since that depends on the user's system on which the package will be installed. So we can't add those files to the package manifest. They could be installed dynamically by a maintainer script (that gets triggered at package installation time) but that's less than ideal because then we'll need to also add machinery to properly track deletions so that when they're dependencies get removed we can remove the scripts too. This is something that's very much frowned upon in Debian, especially for /usr/bin scripts. |
|
|
| msg313222 - (view) |
Author: Cheryl Sabella (cheryl.sabella) * |
Date: 2018-03-04 22:26 |
| Is there still interest in this? Should it be converted to a PR for 3.8? |
|
|
| msg313223 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2018-03-04 22:34 |
| -0.5. I have mixed feelings about this. While I can see the utility of it, I think more recently we have been moving away from the concept of installed scripts for standard library features primarily because they are difficult to manage when there are multiple versions of Python installed and with virtual environments. Speaking of which, how would this work in practice within venvs? And how would it work with the Windows launcher, py? |
|
|
| msg322398 - (view) |
Author: Berker Peksag (berker.peksag) * |
Date: 2018-07-26 05:54 |
| I agree with Ned. I've been using "python -m foo" instead of "foo" more in the past few years. pyvenv has been deprecated in Python 3.6 and its documentation now uses "python -m venv". +1 for closing this as "rejected". |
|
|