setup.py test is going to be deprecated #5534
Labels
good first issue
easy issue that is friendly to new contributor
type: docs
documentation improvement, missing or needing clarification
Comments
|
Definitely, thanks for bringing this to attention. We might even consider removing that section altogether I think, only keeping the |
|
@jaraco what do you think? |
nicoddemus
added
good first issue
|
setting setup_requires in 'setup.py' is not good practice, it should be moved to |
|
I agree we should discourage use of
Yes, I'm in favor of removing the section altogether. I don't see any value in keeping a reference to pytest-runner. Instead, I recommend giving users guidance on how best to orchestrate (create environments, declare and install dependencies, etc) their tests (e.g. with |
graingert
added a commit
to graingert/pytest
that referenced
this issue
Jul 3, 2019
integrating with `python setup.py test` is not good practice!
This was referenced Jul 3, 2019
nicoddemus
added a commit
that referenced
this issue
Jul 3, 2019
|
I'd be tempted to include a recommendation to not integrate with setuptools, rather than just have the section disappear. Otherwise people won't understand why it's gone. |
|
@jamesmyatt that's a good suggestion. Would you like to open a short PR with that? I suppose this can be done even directly from the GH interface. 👍 |
|
Closed by #5546 |
sqlalchemy-bot
pushed a commit
to sqlalchemy/mako
that referenced
this issue
Aug 1, 2019
Removed the "python setup.py test" feature in favor of a straight run of "tox". Per Pypa / pytest developers, "setup.py" commands are in general headed towards deprecation in favor of tox. The tox.ini script has been updated such that running "tox" with no arguments will perform a single run of the test suite against the default installed Python interpreter. .. seealso:: pypa/setuptools#1684 pytest-dev/pytest#5534 Fixes: #303 Change-Id: I345fd46f8911a71c039adf2d51937175142db793
sqlalchemy-bot
pushed a commit
to sqlalchemy/alembic
that referenced
this issue
Aug 26, 2019
Removed the "python setup.py test" feature in favor of a straight run of
"tox". Per Pypa / pytest developers, "setup.py" commands are in general
headed towards deprecation in favor of tox. The tox.ini script has been
updated such that running "tox" with no arguments will perform a single run
of the test suite against the default installed Python interpreter.
.. seealso::
pypa/setuptools#1684
pytest-dev/pytest#5534
Change-Id: Ib92ef8d20ad0e6f1e1b9d25051b788788cc69b02
Fixes: #592
akx
added a commit
to akx/django-enumfields2
that referenced
this issue
Jan 16, 2020
akx
added a commit
to hzdg/django-enumfields
that referenced
this issue
Jan 16, 2020
N-Coder
added a commit
to ics-py/ics-py
that referenced
this issue
May 16, 2020
For my current PR #240 I'm adding `hypothesis` as a test dependency to allow generation of random input strings to better test parsing and escaping logic (see e44e4b3). I also changed how we load the grammar file, to make the package zip safe again (see 3cafe53). While working on how these could be integrated into our testsuite, I found out that `setup.py test` is deprecated ([1](pytest-dev/pytest#5534) [2](https://tox.readthedocs.io/en/latest/example/basic.html#integration-with-setup-py-test-command)). The recommendation was to use `tox` to test the generated package directly using `pytest` instead of relying on `setup.py` to test the sources. Additionally, there's a designated successor to `setup.py` and `setup.cfg` (in which we probably accumulated a few outdated definitions), the build-system independent `pyproject.toml`. Additionally, there are newer tools like `pipenv`, `flit` and `poetry` to help with the whole build and publishing process. As I was not quite happy with how the whole development process of ics.py was set up, I wanted to give them a shot. Collecting some opinion around the internet, it seemed that `flit` was mostly targeted at very simple low-configuration projects and the development of `pipenv` somehow stagnated, while `poetry` seemed to be a well suited solution. So this PR contains my attempt at migrating to `poetry`, with all ics.py sources moved according to the new recommended format. It's mostly the config files in the root directory that changed, but I also removed the `dev` directory as it should no longer be needed. Next to all files from the `./ics/` directory remain unchanged and are simply moved to `./src/ics/`. I didn't copy the tests over yet, as I plan to rewrite most of them in my other branch. The first of the two main configuration files is now `pyproject.toml`, where all meta-information on the project and how it can be installed (i.e. dependencies) and built are stored (without the need to actually execute the file and have some specific setuptools lying around). The second is `tox.ini`, where all testing related functionality is configured. A third file `.bumpversion.cfg` is from a small tool that helps with updating the version number in all places when doing a new release. The `poetry.lock` file optionally stores the dependency versions against which we want to develop, which is independent from the versions the library pulls in as dependency itself, where we are pretty liberal, and the versions we test against, which is always the latest releases. All library sourcecode now resides within a `src` folder, which is recommended as it prevents you from accidentally having the sources in your PATH when you want to test the final package. The root directory now looks very clean and all those files have their specific purpose. If you want to configure how testing is done, you find all information in [`tox.ini`](https://github.com/N-Coder/ics.py-poetry/blob/master/tox.ini). If you want to run the tests (i.e. pytest, doctest, flake8, mypy and check that the docs build), simply run `tox` - you don't have to worry about which versions in which venvs are installed and whether you're directly testing against the sources or against a built package, tox handles all that for you. This not only comes in very handy when running the tests manually, but should also ensure that [CI](https://github.com/N-Coder/ics.py-poetry/blob/master/.github/workflows/pythonpackage.yml) does exactly the same. On a side note, we're now again publishing [coverage data](https://codecov.io/gh/N-Coder/ics.py-poetry). If you just want to run the tests and don't need to fiddle around with the development version of ics in an interactive shell, that's all you need. For the fiddling part, just run [`poetry install`](https://python-poetry.org/docs/cli/#install) and you will have a turnkey development environment set up. Use `poetry shell` or `poetry run` to easily access the venv poetry set up for you. Publishing is now also very simple: just call `poetry publish --build` and the tool will take care of the rest. This made it very easy to make some releases on the [testing pypi instance](https://test.pypi.org/project/ics/#history). The third and last tool you might want is `bumpversion`, if you are making new releases. But there is no need anymore to handle any venvs yourself or to install all ics.py dependencies globally. To summarize, if you want to hit the ground running and publish a new release on a newly set-up machine, the following should suffice: ```bash git clone https://github.com/N-Coder/ics.py-poetry.git && cd ics.py-poetry pip install tox poetry bumpversion --user tox # make sure all the test run bumpversion --verbose release # 0.8.0-dev -> 0.8.0 (release) poetry build # build the package tox --recreate # ensure that the version numbers are consistent # check changelog and amend if necessary git push && git push --tags poetry publish # publish to pypi bumpversion --verbose minor # 0.8.0 (release) -> 0.9.0-dev git push && git push --tags ``` You can try that out if you want -- except for the publishing part maybe. Also note that `bumpversion` directly makes a commit with the new version if you don't pass `--no-commit` or `--dry-run`, but that's no problem as you can easily amend any changes you want to make, e.g. to the changelog. The above information on developing, testing and publishing can now also be found in the docs (see CONTRIBUTING.rst). As these changes are partially based upon #240 but are also quite fundamental, I wanted to collect feedback first before including the changes into #240. The only other thing #240 is still lacking is more testing (only few files already have close to 100% coverage), and I'd prefer to provide that using `tox` in this new environment. So that's also some kind of cyclic dependency. Sorry for the (now superfluous) issue I opened before. So @C4ptainCrunch (and maybe also @aureooms and @tomschr), what's your opinion on this? * migrate repo structure to poetry * fix src path for pytest * add doc skeleton * implement handling of attachments * import project files * set version * fix sphinx build with poetry * don't use poetry within tox see python-poetry/poetry#1941 (comment) * fix timezone tests * change coveralls action * try codecov * bugfixes * add bumpversion * separate src inspection (flake8+mypy src/) from package testing (pytest tests/) to fix PATH problems * bugfixes * Merge branch 'master' into new-parser-impl * remove old files * add dev and publish instructions * checker happiness `noqa` and `type: ignore` are now only used for actual bugs in the checkers unfortunately, current pyflakes dislikes `type: ignore[something]`, so we can't ignore specific mypy bugs until pyflakes 2.2 is in flakes8 * more checker happiness * Apply suggestions from code review Co-Authored-By: Tom Schraitle <[email protected]> * use gitignore directly from github instead of gitignore.io * Apply suggestions from code review to tox.ini * fix tox.ini * add pypy support Mostly by moving/splitting test dependencies to different sections in tox.ini as mypy and pypy don't work well together and it is sufficient to run mypy checks on CPython. * update developing documentation * fix non-ASCII whitespace handling * update test/dev dependencies
N-Coder
added a commit
to ics-py/ics-py
that referenced
this issue
May 16, 2020
For my current PR #240 I'm adding `hypothesis` as a test dependency to allow generation of random input strings to better test parsing and escaping logic (see e44e4b3). I also changed how we load the grammar file, to make the package zip safe again (see 3cafe53). While working on how these could be integrated into our testsuite, I found out that `setup.py test` is deprecated ([1](pytest-dev/pytest#5534) [2](https://tox.readthedocs.io/en/latest/example/basic.html#integration-with-setup-py-test-command)). The recommendation was to use `tox` to test the generated package directly using `pytest` instead of relying on `setup.py` to test the sources. Additionally, there's a designated successor to `setup.py` and `setup.cfg` (in which we probably accumulated a few outdated definitions), the build-system independent `pyproject.toml`. Additionally, there are newer tools like `pipenv`, `flit` and `poetry` to help with the whole build and publishing process. As I was not quite happy with how the whole development process of ics.py was set up, I wanted to give them a shot. Collecting some opinion around the internet, it seemed that `flit` was mostly targeted at very simple low-configuration projects and the development of `pipenv` somehow stagnated, while `poetry` seemed to be a well suited solution. So this PR contains my attempt at migrating to `poetry`, with all ics.py sources moved according to the new recommended format. It's mostly the config files in the root directory that changed, but I also removed the `dev` directory as it should no longer be needed. Next to all files from the `./ics/` directory remain unchanged and are simply moved to `./src/ics/`. I didn't copy the tests over yet, as I plan to rewrite most of them in my other branch. The first of the two main configuration files is now `pyproject.toml`, where all meta-information on the project and how it can be installed (i.e. dependencies) and built are stored (without the need to actually execute the file and have some specific setuptools lying around). The second is `tox.ini`, where all testing related functionality is configured. A third file `.bumpversion.cfg` is from a small tool that helps with updating the version number in all places when doing a new release. The `poetry.lock` file optionally stores the dependency versions against which we want to develop, which is independent from the versions the library pulls in as dependency itself, where we are pretty liberal, and the versions we test against, which is always the latest releases. All library sourcecode now resides within a `src` folder, which is recommended as it prevents you from accidentally having the sources in your PATH when you want to test the final package. The root directory now looks very clean and all those files have their specific purpose. If you want to configure how testing is done, you find all information in [`tox.ini`](https://github.com/N-Coder/ics.py-poetry/blob/master/tox.ini). If you want to run the tests (i.e. pytest, doctest, flake8, mypy and check that the docs build), simply run `tox` - you don't have to worry about which versions in which venvs are installed and whether you're directly testing against the sources or against a built package, tox handles all that for you. This not only comes in very handy when running the tests manually, but should also ensure that [CI](https://github.com/N-Coder/ics.py-poetry/blob/master/.github/workflows/pythonpackage.yml) does exactly the same. On a side note, we're now again publishing [coverage data](https://codecov.io/gh/N-Coder/ics.py-poetry). If you just want to run the tests and don't need to fiddle around with the development version of ics in an interactive shell, that's all you need. For the fiddling part, just run [`poetry install`](https://python-poetry.org/docs/cli/#install) and you will have a turnkey development environment set up. Use `poetry shell` or `poetry run` to easily access the venv poetry set up for you. Publishing is now also very simple: just call `poetry publish --build` and the tool will take care of the rest. This made it very easy to make some releases on the [testing pypi instance](https://test.pypi.org/project/ics/#history). The third and last tool you might want is `bumpversion`, if you are making new releases. But there is no need anymore to handle any venvs yourself or to install all ics.py dependencies globally. To summarize, if you want to hit the ground running and publish a new release on a newly set-up machine, the following should suffice: ```bash git clone https://github.com/N-Coder/ics.py-poetry.git && cd ics.py-poetry pip install tox poetry bumpversion --user tox # make sure all the test run bumpversion --verbose release # 0.8.0-dev -> 0.8.0 (release) poetry build # build the package tox --recreate # ensure that the version numbers are consistent # check changelog and amend if necessary git push && git push --tags poetry publish # publish to pypi bumpversion --verbose minor # 0.8.0 (release) -> 0.9.0-dev git push && git push --tags ``` You can try that out if you want -- except for the publishing part maybe. Also note that `bumpversion` directly makes a commit with the new version if you don't pass `--no-commit` or `--dry-run`, but that's no problem as you can easily amend any changes you want to make, e.g. to the changelog. The above information on developing, testing and publishing can now also be found in the docs (see CONTRIBUTING.rst). As these changes are partially based upon #240 but are also quite fundamental, I wanted to collect feedback first before including the changes into #240. The only other thing #240 is still lacking is more testing (only few files already have close to 100% coverage), and I'd prefer to provide that using `tox` in this new environment. So that's also some kind of cyclic dependency. Sorry for the (now superfluous) issue I opened before. So @C4ptainCrunch (and maybe also @aureooms and @tomschr), what's your opinion on this? * migrate repo structure to poetry * fix src path for pytest * add doc skeleton * implement handling of attachments * import project files * set version * fix sphinx build with poetry * don't use poetry within tox see python-poetry/poetry#1941 (comment) * fix timezone tests * change coveralls action * try codecov * bugfixes * add bumpversion * separate src inspection (flake8+mypy src/) from package testing (pytest tests/) to fix PATH problems * bugfixes * Merge branch 'master' into new-parser-impl * remove old files * add dev and publish instructions * checker happiness `noqa` and `type: ignore` are now only used for actual bugs in the checkers unfortunately, current pyflakes dislikes `type: ignore[something]`, so we can't ignore specific mypy bugs until pyflakes 2.2 is in flakes8 * more checker happiness * Apply suggestions from code review Co-Authored-By: Tom Schraitle <[email protected]> * use gitignore directly from github instead of gitignore.io * Apply suggestions from code review to tox.ini * fix tox.ini * add pypy support Mostly by moving/splitting test dependencies to different sections in tox.ini as mypy and pypy don't work well together and it is sufficient to run mypy checks on CPython. * update developing documentation * fix non-ASCII whitespace handling * update test/dev dependencies
reszelaz
added a commit
to reszelaz/sardana
that referenced
this issue
Jun 10, 2020
This was referenced Jun 30, 2020
9 tasks
9 tasks
This was referenced Oct 9, 2021
danfowler
added a commit
to omise/omise-python
that referenced
this issue
Jun 19, 2023
marcfrederick
added a commit
to mwclient/mwclient
that referenced
this issue
Aug 24, 2024
The setup.py test command and pytest-runner have been deprecated for several years and are no longer recommended. The pytest documentation no longer recommends pytest-runner and their own documentation recommends against it. - pypa/setuptools#1684 - pytest-dev/pytest#5534 - pytest-dev/pytest-runner#50 Changes made: - Removed pytest-runner: Eliminated the use of pytest-runner from `setup.py`. - Moved test dependencies to the `extra-dependencies`, which can be used by tox as well as for manual installation. - Updated the documentation to recommend using tox as the default test runner. Alternatively, users can manually run tests with the `py.test` command. These changes will also make an eventual migration to `pyproject.toml` easier, as the `extras_require` can be copied to the `project.optional-dependencies` section.
AdamWill
pushed a commit
to mwclient/mwclient
that referenced
this issue
Aug 25, 2024
The setup.py test command and pytest-runner have been deprecated for several years and are no longer recommended. The pytest documentation no longer recommends pytest-runner and their own documentation recommends against it. - pypa/setuptools#1684 - pytest-dev/pytest#5534 - pytest-dev/pytest-runner#50 Changes made: - Removed pytest-runner: Eliminated the use of pytest-runner from `setup.py`. - Moved test dependencies to the `extra-dependencies`, which can be used by tox as well as for manual installation. - Updated the documentation to recommend using tox as the default test runner. Alternatively, users can manually run tests with the `py.test` command. These changes will also make an eventual migration to `pyproject.toml` easier, as the `extras_require` can be copied to the `project.optional-dependencies` section.
st4r1ight
pushed a commit
to st4r1ight/mwclient
that referenced
this issue
Aug 28, 2024
The setup.py test command and pytest-runner have been deprecated for several years and are no longer recommended. The pytest documentation no longer recommends pytest-runner and their own documentation recommends against it. - pypa/setuptools#1684 - pytest-dev/pytest#5534 - pytest-dev/pytest-runner#50 Changes made: - Removed pytest-runner: Eliminated the use of pytest-runner from `setup.py`. - Moved test dependencies to the `extra-dependencies`, which can be used by tox as well as for manual installation. - Updated the documentation to recommend using tox as the default test runner. Alternatively, users can manually run tests with the `py.test` command. These changes will also make an eventual migration to `pyproject.toml` easier, as the `extras_require` can be copied to the `project.optional-dependencies` section.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are plans to deprecate
setup.py test(pypa/setuptools#1684). Is it worth updating the section in "Good Integration Practices" to discourage using the setuptools integration (https://docs.pytest.org/en/latest/goodpractices.html#integrating-with-setuptools-python-setup-py-test-pytest-runner)?The text was updated successfully, but these errors were encountered: