From b57b5c7e38a46f192217062bc4076e75e23e8431 Mon Sep 17 00:00:00 2001 From: Phillip Baker Date: Mon, 19 Aug 2024 21:58:53 -0400 Subject: [PATCH] [tools] Remove setup.py test command `setuptools.command.test` after version 72 of setuptools has been replaced with a stub. Due to this, imports like `from setuptools.command.test import ...` no longer work. Since setup.py test has been deprecated for years, remove it in favor of directly installing dependencies and invoking pytest locally and in CI. Closes https://github.com/suds-community/suds/issues/105 --- HACKING.rst | 275 +++++++------------------------ setup.py | 178 +------------------- tools/suds_devel/requirements.py | 173 ------------------- 3 files changed, 60 insertions(+), 566 deletions(-) diff --git a/HACKING.rst b/HACKING.rst index 2845bc2a..9139f1bd 100644 --- a/HACKING.rst +++ b/HACKING.rst @@ -108,128 +108,27 @@ states aiming for Python 2.4 compatibility we do so as well. The Python 3.0 minor release is not supported. See `Python 3.0 support`_ subsection below for more detailed information. -Test & setup code needs to be implemented using Python 2 & 3 compatible source +Test & setup code needs to be implemented using Python 3 compatible source code. Setup & setup related scripts need to be implemented so they do not rely on other pre-installed libraries. These backward compatibility requirements do not affect internal development operations such as ``setup.py`` support for uploading a new project distribution -package to PyPI. Such operations need to be supported on the latest Python 2 & 3 +package to PyPI. Such operations need to be supported on the latest Python 3 releases only and no additional backward compatibility is either tested or guaranteed for them. The following is a list of backward incompatible Python features not used in this project to maintain backward compatibility: -Features missing prior to Python 2.5 ------------------------------------- - -* ``any`` & ``all`` functions. -* ``with`` statement. -* BaseException class introduced and KeyboardInterrupt & SystemExit exception - classes stopped being Exception subclasses. - - * This means that code wanting to support Python versions prior to this - release needs to re-raise KeyboardInterrupt & SystemExit exceptions before - handling the generic 'Exception' case, unless it really wants to gobble up - those special infrastructural exceptions as well. - -* ``try``/``except``/``finally`` blocks. - - * Prior to this Python release, code like the following:: - - try: - A - except XXX: - B - finally: - C - - was considered illegal and needed to be written using nested ``try`` blocks - as in:: - - try: - try: - A - except XXX: - B - finally: - C - -* ``yield`` expression inside a ``try`` block with a ``finally`` clause. - - * Prior to this Python release, code like the following:: - - try: - yield x - finally: - do_something() - - is considered illegal, but can be replaced with legal code similar to the - following:: - - try: - yield x - except: - do_something() - raise - do_something() - -Features missing prior to Python 2.6 ------------------------------------- - -* ``bytes`` type. -* Byte literals, e.g. ``b"quack"``. -* Class decorators. -* ``fractions`` module. -* ``numbers`` module. -* String ``format()`` method. -* Using the ``with`` statement from Python 2.5.x requires the ``from __future__ - import with_statement``. - - -Features missing prior to Python 2.7 ------------------------------------- - -* Dictionary & set comprehensions. -* Set literals. - -Features missing in Python 3.0 & 3.1 ------------------------------------- - -* py2to3 conversion for source files with an explicitly specified UTF-8 BOM. - - -Python 3.0 support ------------------- - -Python 3.0 release has been marked as deprecated almost immediately after the -release 3.1. It is not expected that this Python release is actively used -anywhere in the wild. That said, if anyone really wants this version supported -- patches are welcome. - -At least the following problems have been found with Python 3.0: - -* None of the tools required to properly test our project (setuptools, pip, - virtualenv, tox, etc.) will work on it. -* When you attempt to setuptools project with Python 3.0, it attempts to use the - ``sys.stdout.detach()`` method introduced only in Python 3.1. This specific - issue could be worked around by using ``sys.stdout.buffer`` directly but the - actual fix has not been attempted. If anyone wants to take this route though - and work on supporting setuptools on Python 3.0 - be warned that it will most - likely have other issues after this one as well. -* When applying py2to3 to the project sources, Python will use the current - user's locale encoding instead of the one specified in the project sources, - thus causing the operation to fail on some source files containing different - unicode characters unless the user's environement uses some sort of unicode - encoding by default, e.g. will fail on some test scripts when run on Windows - with eastern European regional settings (uses the CP1250 encoding). +N/A - None at this time +----------------------- RELEASE PROCEDURE ================================================= -1. Document the release correctly in ``README.rst``. +1. Document the release correctly in ``README.rst`` and ``CHANGELOG.md``. 2. Test the project build with the latest available ``setuptools`` project. @@ -242,14 +141,13 @@ RELEASE PROCEDURE 2.5 and so ``setup.py`` uses a separate ``ez_setup_1_4_2.py`` ``setuptools`` installation script with Python versions older than 2.6. -3. Version identification. +3. Version identification follows semantic versioning. * Official releases marked with no extra suffix after the basic version number. - * Alfa releases marked with the suffix ``.a#``. - * Beta releases marked with the suffix ``.b#``. - * Release candidate releases marked with the suffix ``.rc#``. - * Development releases marked with the suffix ``.dev#``. + * Alfa releases marked with the suffix ``.alpha.#``. + * Beta releases marked with the suffix ``.beta.#``. + * Release candidate releases marked with the suffix ``.rc.#``. * Version ordering (as recognized by pip & setuptools):: 0.5.dev0 < 0.5.dev1 < 0.5.dev5 @@ -270,11 +168,11 @@ RELEASE PROCEDURE ... < 1.0 -4. Tag in Hg. +4. Tag in git. - * Name the tag like ``release-``, e.g. ``release-0.5``. + * Name the tag like ``v``, e.g. ``v0.5.0``. -5. Prepare official releases based only on tagged commits. +5. Prepare official releases based only on tagged commits. Generally this can be done by pushing the new tag to Github and a workflow on Github Actions will build and push to PyPi. A manual approach is described below. * Official releases should always be prepared based on tagged revisions with no local changes in the used sandbox. @@ -283,14 +181,14 @@ RELEASE PROCEDURE * Run ``setup.py sdist upload``. - * Prepare wheel packages for Python 2 & 3 using the latest Python 2 & 3 + * Prepare wheel packages for Python 3 using the latest Python 3 environments with the ``wheel`` package installed and upload them to PyPI. - * Run ``setup.py bdist_wheel upload`` using both Python 2 & 3. + * Run ``setup.py bdist_wheel upload`` using both Python 3. * Upload the prepared source & wheel packages to the project site. - * Use the BitBucket project web interface. + * Use the Github project web interface. 6. Next development version identification. @@ -318,23 +216,14 @@ respectively. Setting up the development & testing environment ------------------------------------------------ -``tools/setup_base_environments.py`` script should be used for setting up the -basic Python environments so they support testing our project. The script can be -configured from the main project Python configuration file ``setup.cfg``. It -implements all the backward compatibility tweaks and performs additional -required package installation that would otherwise need to be done manually in -order to be able to test our project in those environments. - -These exact requirements and their related version specific tweaks are not -documented elsewhere so anyone interested in the details should consult the -script's sources. - -The testing environment is generally set up as follows: +This package is tested against multiple versions of Python using the 1. Install clean target Python environments. -#. Update the project's ``setup.py`` configuration with information on your - installed Python environments. -#. Run the ``tools/setup_base_environments.py`` script. +#. Install project requirements: ``pip install -r requirements.txt`` + +Note: An older script to setup mulitple python interprets exists in the +``tools/setup_base_environments.py`` script. This is not maintained and may +be removed. Some older Python environments may have slight issues caused by varying support levels in different used Python packages, but the basic testing functionality @@ -345,93 +234,6 @@ Examples of such issues: * Colors not getting displayed on a Windows console terminal, with possibly ANSI color code escape sequences getting displayed instead. -* ``pip`` utility can not be run from the command-line using the ``py -m pip`` - syntax for some older versions. In such cases use the more portable ``py -c - "import pip;pip.main()"`` syntax instead. -* Some specific older Python versions (e.g. 2.4.3) have no SSL support and so - have to reuse installations downloaded by other Python versions. - -Running the project tests - ``tools/run_all_tests.py`` script -------------------------------------------------------------- - -``tools/run_all_tests.py`` script is a basic *poor man's tox* development script -that can be used for running the full project test suite using multiple Python -interpreter versions on a development machine. - -Intended to be replaced by a more portable ``tox`` based or similar automated -testing solution some time in the future. - -Can be configured by tweaking the main project Python configuration file -``setup.cfg``: - -* List of target Python environments. -* Each target Python environment's invocation command. - -Requires the target Python environment already be set up, and all the packages -required for running the project test suite installed. See the `Setting up the -development & testing environment`_ section for more detailed information. - -Automatically installs the project in editable mode in all tested Python -environments. - -Caveats: - -* This method does not allow you to provide any extra ``pytest`` options when - running the project test suite. - -Running the project tests - ``setup.py test`` command ------------------------------------------------------ - -Project tests can also be run for a specific Python environment by running the -project's ``setup.py`` script in that environment and invoking its ``test`` -command. E.g. run a command like one of the following ones from the top level -project folder:: - - py243 setup.py test - py27 setup.py test - py3 setup.py test - -Note that the ``setup.py`` script always needs to be called from the top level -project folder. - -For most Python versions, the target Python environment needs not be set up -prior to running this command. Where possible (e.g. not for Python 2.4.x or -3.1.x versions), any missing testing requirements will be installed -automatically, but not directly into the target environment but in the current -folder instead. This functionality should be considered a band-aid though, and -setting up the target environment can be better done as described in the -`Setting up the development & testing environment`_ section. - -The ``setup.py test`` command will build the project if needed and run its test -suite in the target Python environment. The project does not need to be -preinstalled into the target Python environment for this operation to work, and -neither will the operation leave it installed. - -Unless a more restricted test set is selected using ``pytest`` specific -command-line options, ``setup.py test`` command runs the complete project test -suite. - -Specific ``pytest`` command-line options may be provided by passing them all as -a single whitespace separated string tunnelled via the ``setup.py test`` -command's ``--pytest-args``/``-a`` command-line option. - -For example, the following command will run only tests containing ``binding`` in -their name, will stop on first failure and will automatically drop into Python's -post-mortem debugger on failure:: - - setup.py test -a "-k binding -x --pdb" - -Caveats: - -* This method does not currently allow passing ``pytest`` specific command-line - options containing embedded whitespace. -* When running the ``setup.py test`` command in a Windows Python 2.5 environment - without an included ctypes module (e.g. 64-bit CPython 2.5 distribution does - not include ctypes) and having it automatically install the colorama package - version older than 0.1.11, you will get benign error messages reporting - colorama's atexit handlers failing. Running the same command again avoids the - issue since the colorama package will then already be installed. Suggested - workaround is to use a colorama package version 0.3.2 or newer. Running the project tests - using ``pytest`` directly ----------------------------------------------------- @@ -519,6 +321,41 @@ options. Some interesting ones: -x stop on first failure --pdb enter Python debugger on failure +Running the project tests - ``tools/run_all_tests.py`` script +------------------------------------------------------------- + +This is no longer supported and may be removed. + +``tools/run_all_tests.py`` script is a basic *poor man's tox* development script +that can be used for running the full project test suite using multiple Python +interpreter versions on a development machine. + +Intended to be replaced by a more portable ``tox`` based or similar automated +testing solution some time in the future. + +Can be configured by tweaking the main project Python configuration file +``setup.cfg``: + +* List of target Python environments. +* Each target Python environment's invocation command. + +Requires the target Python environment already be set up, and all the packages +required for running the project test suite installed. See the `Setting up the +development & testing environment`_ section for more detailed information. + +Automatically installs the project in editable mode in all tested Python +environments. + +Caveats: + +* This method does not allow you to provide any extra ``pytest`` options when + running the project test suite. + +Running the project tests - ``setup.py test`` command +----------------------------------------------------- + +Removed as setuptools has removed support for ``setup.py test`` after version 72. + Setting up multiple parallel Python interpreter versions on Windows ------------------------------------------------------------------- diff --git a/setup.py b/setup.py index eede1536..6940ccef 100644 --- a/setup.py +++ b/setup.py @@ -37,45 +37,15 @@ """ import sys -if sys.version_info < (2, 4): - print("ERROR: Python 2.4+ required") - sys.exit(-2) -if (3,) <= sys.version_info < (3, 1): - print("ERROR: Python 3.0 not supported - please use Python 3.1+ instead") - sys.exit(-2) - import os import os.path import re -# Workaround for a Python issue detected with Python 3.1.3 when running our -# pytest based 'setup.py test' command. At the end of the test run, Python -# would report an error: -# -# > Error in atexit._run_exitfuncs: -# > TypeError: print_exception(): Exception expected for value, str found -# -# Workaround found suggested by Richard Oudkerk in Python's issue tracker at: -# http://bugs.python.org/issue15881#msg170215 -# -# The error is caused by two chained Python bugs: -# 1. The multiprocessing module seems to call its global cleanup function only -# after all of its globals have already been released, thus raising an -# exception. -# 2. atexit exception handling implementation is not prepared to handle and -# correctly report the exception as raised by the multiprocessing module -# cleanup. -if (3,) <= sys.version_info < (3, 2): - import multiprocessing - del multiprocessing - - # ----------------------------------------------------------------------------- # Global variables. # ----------------------------------------------------------------------------- distutils_cmdclass = {} -extra_setup_params = {} # ----------------------------------------------------------------------------- # Detect the setup.py environment - current & script folder. @@ -114,10 +84,6 @@ import suds_devel sys.path.pop(0) -from suds_devel.requirements import (check_Python24_pytest_requirements, - pytest_requirements) - - # ----------------------------------------------------------------------------- # Attempt to use setuptools for this installation. # ----------------------------------------------------------------------------- @@ -334,141 +300,6 @@ def unicode2ascii(unicode): exec(read_python_code(os.path.join(script_folder, "suds", "version.py"))) -# ----------------------------------------------------------------------------- -# Custom setup.py 'test' command for running the project test suite. -# ----------------------------------------------------------------------------- -# pytest and any of its requirements not already installed in the target Python -# environment will be automatically downloaded from PyPI and installed into the -# current folder as zipped egg distributions. -# -# Requirements: -# - setup must be using setuptools -# - if running Python version prior to 2.5, a suitable pytest version must -# already be installed and will not be installed on demand (see the related -# embedded code comment below for more detailed information) -# -# If the requirements are not met, the command simply reports an end-user error -# message explaining why the test functionality is unavailable. -# -# Since Python's distutils framework does not allow passing all received -# command-line arguments to its commands, it does not seem easy to customize -# how pytest runs its tests this way. To have better control over this, user -# should run the pytest on the target source tree directly, possibly after -# first building a temporary one to work around problems like Python 2/3 -# compatibility. - -def test_requirements(): - """ - Return test requirements for the 'test' command or an error string. - - An error is reported if the requirements can not be satisfied for some - reason. - - Exact required packages and their versions vary depending on our target - Python environment version as pytest dropped backward compatibility support - for some of the Python versions we still support in this project. - - """ - if not using_setuptools: - return "test command not available without setuptools" - - include_pytest_requirements = True - - # When using Python 2.5 on Windows, if setuptools chooses to install the - # colorama package (pytest requirement on Windows) older than version - # 0.1.11, running our 'setup.py test' command may show benign error - # messages caused by some colorama atexit handlers getting triggered - # multiple times. There are no adverse effects to this and the issue only - # occurs if the package is not already installed and it is the 'setup.py - # test' command that is installing it. The issue has been fixed by the next - # Python 2.5 compatible colorama 0.3.2 release. - result = [] - if include_pytest_requirements: - result.extend(pytest_requirements()) - return result - -test_error = None -tests_require = test_requirements() -if isinstance(tests_require, str): - test_error = tests_require -else: - extra_setup_params["tests_require"] = tests_require - -if test_error: - import distutils.cmd - import distutils.errors - - class TestCommand(distutils.cmd.Command): - description = test_error - user_options = [] - def initialize_options(self): - pass - def finalize_options(self): - pass - def run(self): - raise distutils.errors.DistutilsPlatformError(self.description) -else: - from setuptools.command.test import (normalize_path as _normalize_path, - test as _test) - - class TestCommand(_test): - # Derived from setuptools.command.test.test for its - # with_project_on_sys_path() method. - - description = "run pytest based unit tests after a build" - - # Override base class's command-line options. - #TODO: pytest argument passing support could be improved if we could - # get distutils/setuptools to pass all unrecognized command-line - # parameters to us instead of complaining about them. - user_options = [("pytest-args=", "a", "arguments to pass to pytest " - "(whitespace separated, whitespaces in arguments not supported)")] - - def initialize_options(self): - self.pytest_args = None - - def finalize_options(self): - self.test_args = [] - if self.pytest_args is not None: - self.test_args = self.pytest_args.split() - - def run(self): - # shamelessly lifted from setuptools.command.test.test.run() - dist = self.distribution - if dist.install_requires: - dist.fetch_build_eggs(dist.install_requires) - if dist.tests_require: - dist.fetch_build_eggs(dist.tests_require) - - cmd = self._test_cmd_string() - if self.dry_run: - self.announce("skipping '%s' (dry run)" % (cmd,)) - else: - self.announce("running '%s'" % (cmd,)) - self.with_project_on_sys_path(self.run_tests) - - def run_tests(self): - import pytest - sys.exit(pytest.main(self.test_args)) - - def _test_cmd_string(self): - parts = ["pytest"] - if self.pytest_args: - parts.append(self.pytest_args) - return " ".join(parts) - -distutils_cmdclass["test"] = TestCommand - - -# ----------------------------------------------------------------------------- -# Mark the original suds project as obsolete. -# ----------------------------------------------------------------------------- - -if sys.version_info >= (2, 5): - # distutils.setup() 'obsoletes' parameter not introduced until Python 2.5. - extra_setup_params["obsoletes"] = ["suds"] - - # ----------------------------------------------------------------------------- # Avoid setup warnings when constructing a list of all project sources. # ----------------------------------------------------------------------------- @@ -522,7 +353,8 @@ def _test_cmd_string(self): distribution). """ -package_name = os.environ.get('SUDS_PACKAGE', 'suds-community') +forked_package_name = 'suds-community' +package_name = os.environ.get('SUDS_PACKAGE', forked_package_name) version_tag = safe_version(__version__) project_url = "https://github.com/suds-community/suds" base_download_url = project_url + "/archive" @@ -570,8 +402,6 @@ def _test_cmd_string(self): license="(specified using classifiers)", platforms=["(specified using classifiers)"], - # Register distutils command customizations. - cmdclass=distutils_cmdclass, python_requires=">=3.7", - - **extra_setup_params) + obsoletes=["suds"] if package_name == forked_package_name else [], +) diff --git a/tools/suds_devel/requirements.py b/tools/suds_devel/requirements.py index 0af1e7b6..8a399f6d 100644 --- a/tools/suds_devel/requirements.py +++ b/tools/suds_devel/requirements.py @@ -75,179 +75,6 @@ class _Unspecified: pass -_first_unsupported_py_version_on_Python_24 = ( - lowest_version_string_with_prefix("1.4.16")) -_first_unsupported_py_version_on_Python_25 = ( - lowest_version_string_with_prefix("1.4.24")) - -# pytest versions prior to 2.4.0 do not support non-string 'skipif' -# expressions. -_first_supported_pytest_version = "2.4.0" -_first_unsupported_pytest_version_on_Python_24 = ( - lowest_version_string_with_prefix("2.4.2")) -# pytest version 2.6.0 actually supports Python 2.5 but has some internal -# issues causing it to break our our tests, while version 2.6.1 fails to -# install on Python 2.5 all together. -_first_unsupported_pytest_version_on_Python_25 = ( - lowest_version_string_with_prefix("2.6.0")) - - -def check_Python24_pytest_requirements(): - """ - Check pytest requirements in the current Python 2.4.x environment. - - Installing pytest into a Python 2.4.x environment requires specific py & - pytest package versions. This function checks whether the environment has - such compatible Python environments installed. - - Returns a 2-tuple (have_pytest, have_py) indicating whether valid pytest & - py library packages have been detected in the current Python 2.4.x - environment. If the pytest package has not been detected, the py library - package will not be checked and the have_py value will be set to None. - - See the module docstring for more detailed information. - - """ - assert sys.version_info[:2] == (2, 4) - try: - from pytest import __version__ as pytest_version - except ImportError: - return False, None # no pytest - pv_from = parse_version(_first_supported_pytest_version) - pv_to = parse_version(_first_unsupported_pytest_version_on_Python_24) - if not (pv_from <= parse_version(pytest_version) < pv_to): - return False, None # incompatible pytest version - try: - from py import __version__ as py_version - except ImportError: - return True, False # no py library package - pv_unsupported = parse_version(_first_unsupported_py_version_on_Python_24) - if parse_version(py_version) >= pv_unsupported: - return True, False # incompatible py library package version - return True, True - - -def pytest_requirements(version_info=None, ctypes_version=_Unspecified): - """ - Generate Python version specific pytest package requirements. - - The requirements are returned as setuptools/pip compatible requirement - specification strings. - - As a slight optimization, specify no Python version information to indicate - that the requirements are being listed for the current Python environment. - - Missing ctypes installation should be indicated by setting ctypes_version - parameter to None, while not specifying it indicates that no ctypes version - information is provided. - - """ - current_environment = version_info is None - if current_environment: - version_info = sys.version_info - - pytest_version = None - if version_info < (2, 5): - pytest_version = ( - (">=", _first_supported_pytest_version), - ("<", _first_unsupported_pytest_version_on_Python_24)) - yield requirement_spec("py", - ("<", _first_unsupported_py_version_on_Python_24)) - #IDEA: In this case we could run the pytest installation separately - # from all the other pip based installations and have it not install - # pytest scripts. Since in general there is no 'setup.py install' or - # 'pip' command-line argument that can say 'do not install scripts', - # this would most likely need to use a pip command-line option like - # '--install-option="--install-scripts=..."' to make the scripts be - # installed into a temporary folder and then remove that folder after - # the installation. An alternative would be to use easy_install which - # does support the --exclude-scripts command-line option. N.B. This - # could work for the project's Python environment setup scripts but not - # when installing the the project's using its setup script as that - # script expects to set up all the required packages itself. - - # pytest on Windows depends on the colorama package, and that package has - # several accidental backward compatibility issues we have to work around - # when using Python 2.5. - elif version_info < (2, 6): - if sys.platform == "win32": - # colorama releases [0.1.11 - 0.3.2> do not work unless the ctypes - # module is available, but that module is not included in 64-bit - # CPython distributions (tested using Python 2.5.4). Some of those - # versions fail to install, while others only fail at run-time. - # Pull request https://github.com/tartley/colorama/pull/4 resolves - # this issue for colorama release 0.3.2. - if ctypes_version is _Unspecified: - assert current_environment - try: - from ctypes import __version__ as ctypes_version - except ImportError: - ctypes_version = None - if ctypes_version is None: - # We could try to install an external 'ctypes' package from - # PyPI here, but that would require an old C++ compiler and so - # would not be highly likely to work in any concurrent - # development environment. - # - #TODO: When using colorama releases older than 0.1.11, you - # might get atexit() errors on process shutdown after running - # the project's 'setup.py test' command and having it - # automatically install the colorama package in the process. - # The error itself is benign and there are no other effects to - # it other than the error message getting displayed. The whole - # issue is caused by colorama's atexit handler getting called - # multiple times due to some internal setuptools module loading - # and unloading. We found no easy workaround to this so update - # this code to use the colorama package version 0.3.2+ as soon - # as it gets released. When this is done, also remove a related - # setup.py comment. - v_bad_low = lowest_version_string_with_prefix("0.1.11") - v_bad_high = "0.3.2" - version_spec = ("<", v_bad_low), (">=", v_bad_high) - else: - # colorama 0.3.1 release accidentally uses the 'with' keyword - # without a corresponding __future__ import in its setup.py - # script. - version_spec = ("!=", "0.3.1"), - yield requirement_spec("colorama", *version_spec) - - yield requirement_spec("py", - ("<", _first_unsupported_py_version_on_Python_25)) - - pytest_version = ( - (">=", _first_supported_pytest_version), - ("<", _first_unsupported_pytest_version_on_Python_25)) - - # Python 3.0 & 3.1 stdlib does not include the argparse module which pytest - # requires, even though it does not list it explicitly among its - # requirements. Python 3.x series introduced the argparse module in its 3.2 - # release so it needs to be installed manually in 3.0.x & 3.1.x releases. - # Tested that pytest 2.5.2+ requires py 1.4.20+ which in turn requires the - # argparse module but does not specify this dependency explicitly. - elif (3,) <= version_info < (3, 2): - # pytest versions prior to 2.6.0 are not compatible with Python 3.1, - # mostly due to accidental incompatibilities introduced because that is - # not one of the officially supported platforms for pytest and so does - # not get regular testing. Development version 2.6.0 has been tested - # with this project and found to work correctly. - #TODO: Once pytest 2.6.0 has been officially released change the pytest - # requirement to ("==", "2.6.0"). - pytest_version = (">=", lowest_version_string_with_prefix("2.6.0")), - missing_argparse = True - if current_environment: - try: - import argparse - missing_argparse = False - except ImportError: - pass - if missing_argparse: - yield requirement_spec("argparse") - - if not pytest_version: - pytest_version = (">=", _first_supported_pytest_version), - yield requirement_spec("pytest", *pytest_version) - - def virtualenv_requirements(version_info=sys.version_info): """ Generate Python version specific virtualenv package requirements.