Deprecate the test command #1878
Conversation
There was a problem hiding this comment.
Would it be possible to add some tests for this?
Here is the relevant section of the PR deprecating the upload and register commands.
docs/setuptools.txt
Outdated
| @@ -2142,6 +2148,12 @@ distutils configuration file the option will be added to (or removed from). | |||
| ``test`` - Build package and run a unittest suite | |||
| ================================================= | |||
|
|
|||
| .. warning:: | |||
| **test** is deprecated in favor of using `tox | |||
| <https://tox.readthedocs.org/>`_, `unittest | |||
There was a problem hiding this comment.
Should be https://tox.readthedocs.io
Also, I think we can reword this a bit - I'd prefer it to be clear that tox is the actual solution here, and the other two are test runners (plus pytest should probably be prioritized over unittest), I'd word it as:
.. warning::
``test`` is deprecated in favor of using `tox
<https://tox.readthedocs.io>`_, or directly invoking your test runner (e.g.
`pytest <https://docs.pytest.org>`_ or `unittest
<https://docs.python.org/library/unittest.html>`_).Another wording that might put our thumbs on the scale in favor of tox a bit more lightly would be:
.. warning::
``test`` is deprecated and will be removed in a future version. Users looking
for a generic test entry point independent of test runner are encouraged to
use `tox <https://tox.readthedocs.io>`_.
changelog.d/1878.change.rst
Outdated
| @@ -0,0 +1 @@ | |||
| Deprecate ``test`` commands. | |||
There was a problem hiding this comment.
| Deprecate ``test`` commands. | |
| Formally deprecated the ``test`` command, with the recommendation that users migrate to ``tox``. |
|
Thank you @jdufresne for your work! I really appreciate the way you've been quietly (at least in my corner of the universe) and methodically improving the overall health of the Python ecosystem. |
Provide a warning to users. Suggest using tox as an alternative generic entry point. Refs #1684
|
Thanks for the review. I have implemented your suggestions and and added tests. I went with the stronger warning as I really like the "and will be removed in a future version" phrasing, but I'm happy to switch back to the softer wording if preferred. If you're looking for anything else out of the tests, let me know and I'll add them. And thanks very much for the kind words! 🙂 |
|
It may be worth locking this PR and the associated issue and directing people to https://discuss.python.org/ |
|
@graingert Hm.. You're right that this will likely be a magnet for people upset by this news, but I think maybe we should leave it open. That will at least give people who don't want to follow possible objections a single thread (or maybe two threads) to ignore, and some people may indeed have constructive comments to make on the specifics of the implementation. Let's revisit the issue of locking the thread later if the thread becomes toxic (anyone who feels that the thread is going that way, please feel free to send me an e-mail). For anyone coming to this PR to complain or because someone linked it: please be respectful and try to understand the full history of the issue. I know it is voluminous, but please read all of #1684 before commenting. |
|
It's a pity this PR wasn't mentioned in the original discussion about removing the I don't think we should encourage users to use |
|
FYI i found this because while running tests via tox I received this warning I'm new to tox, so I'm not asserting that the implementation is flawed... however, the user experience of running tox then receiving a warning to use tox instead is not great. The package under test in this demo is this cookiecutter template: https://github.com/audreyr/cookiecutter-pypackage with a "hello world" function added/tested. |
|
This is because you ran setup.py test within tox
|
|
@ChadBailey there's already an issue for this audreyfeldroy/cookiecutter-pypackage#500 |
|
@graingert thanks for pointing that out... distribution in python is new territory for me, so plenty to learn. I did not discover (nor consider looking for) an existing bug in the cookiecutter package. Perhaps a quick-fix to the concern I raised is to update the verbiage to the following: I did in fact see the warning in the tox documentation about how integrating tox into setup.py is discouraged due to breaking downstream packages, but still trying to sort all of this out in my mind. If you wouldn't mind, could you confirm if my new understanding the best practice for testing in python is correct?
|
|
@graingert Thanks for your help, I've submitted a PR audreyfeldroy/cookiecutter-pypackage#544 to fix audreyfeldroy/cookiecutter-pypackage#500 |
The "setup.py test" command is deprecated (see pypa/setuptools#1878). I'd like to transition CI to running pytest directly, but for that, I need an easy way to install test dependencies. This provides such a way.
Also replaced tests_require with extras_require. The test command (which tests_required was used for) was deprecated in setuptools 41.5.0. Ref: pypa/setuptools#1878
Also replaced tests_require with extras_require. The test command (which tests_required was used for) was deprecated in setuptools 41.5.0. Ref: pypa/setuptools#1878
|
One thing is for sure, putting test dependencies inside tox.ini is also a bad practice, a convenient one but still bad. This creates a dependency on a tool making very hard to use another test runner than tox. While this was not documented, I have reasons to believe that adding a 'test' |
Using `python setup.py test` is now deprecated [1], users are encouraged
to be explicit about the test command.
Running yamllint tests using the Python standard library (`unittest`)
can be done using:
python -m unittest discover
Why not nose, tox or pytest? Because they would add a dependency, make
tests running more complicated and verbose for new users, and their
benefit is not worth for this simple projects (only 2 runtime
dependencies: PyYAML and pathspec).
[1]: pypa/setuptools#1878
Using `python setup.py test` is now deprecated [1], users are encouraged
to be explicit about the test command.
Running yamllint tests using the Python standard library (`unittest`)
can be done using:
python -m unittest discover
Why not nose, tox or pytest? Because they would add a dependency, make
tests running more complicated and verbose for new users, and their
benefit is not worth for this simple project (only 2 runtime
dependencies: PyYAML and pathspec).
Resolves #328.
[1]: pypa/setuptools#1878
Using `python setup.py test` is now deprecated [1], users are encouraged
to be explicit about the test command.
Running yamllint tests using the Python standard library (`unittest`)
can be done using:
python -m unittest discover
Why not nose, tox or pytest? Because they would add a dependency, make
tests running more complicated and verbose for new users, and their
benefit is not worth for this simple project (only 2 runtime
dependencies: PyYAML and pathspec).
Resolves #328.
[1]: pypa/setuptools#1878
Using `python setup.py test` is now deprecated [1], users are encouraged
to be explicit about the test command.
Running yamllint tests using the Python standard library (`unittest`)
can be done using:
python -m unittest discover
Why not nose, tox or pytest? Because they would add a dependency, make
tests running more complicated and verbose for new users, and their
benefit is not worth for this simple project (only 2 runtime
dependencies: PyYAML and pathspec).
Resolves #328.
[1]: pypa/setuptools#1878
Using `python setup.py test` is now deprecated [1], users are encouraged
to be explicit about the test command.
Running yamllint tests using the Python standard library (`unittest`)
can be done using:
python -m unittest discover
Why not nose, tox or pytest? Because they would add a dependency, make
tests running more complicated and verbose for new users, and their
benefit is not worth for this simple project (only 2 runtime
dependencies: PyYAML and pathspec).
Resolves adrienverge#328.
[1]: pypa/setuptools#1878
`setup.py test` is deprecated for a quite long time: pypa/setuptools#1878
setup.py test has been deprecated with pypa/setuptools#1684 and pypa/setuptools#1878 since setuptools v41.5.0
Refs #1684
Pull Request Checklist