[bumpversion]
-current_version = 46.4.0
+current_version = 47.0.0
commit = True
tag = True
If you did not intend to use this template, but only meant to file a blank issue, just hit the back button and click "Open a blank issue".
-It's by design that Setuptools 45 and later will stop working on Python 2. To ease the transition, Setuptools 45 was released to continue to have Python 2 compatibility, but emit a strenuous warning that it will stop working.
+Setuptools 45 dropped support for Python 2 with a strenuous warning and Setuptools 47 fails to run on Python 2.
In most cases, using pip 9 or later to install Setuptools from PyPI or any index supporting the Requires-Python metadata will do the right thing and install Setuptools 44.x on Python 2.
<!-- These are the recommended workarounds for the issue. Please
try them first. -->
+- [ ] Read [Python 2 Sunset docs](https://setuptools.readthedocs.io/en/latest/python%202%20sunset.html).
- [ ] Python 2 is required for this application.
- [ ] I maintain the software that installs Setuptools (if not, please contact that project).
- [ ] Setuptools installed with pip 9 or later.
- Python installed how:
- Virtualenv version (if using virtualenv): n/a
+Command(s) that triggered the warning/error (and output):
+
+```
+```
+
Command(s) used to install setuptools (and output):
```
jobs:
fast_finish: true
include:
- - &latest_py2
- python: 2.7
- env: TOXENV=py27
- - <<: *latest_py2
- env: LANG=C TOXENV=py27
- python: pypy3
env: DISABLE_COVERAGE=1 # Don't run coverage on pypy (too slow).
- python: 3.5
allow_failures:
# suppress failures due to pypa/setuptools#2000
- python: pypy3
+ - <<: *latest_py3
+ env: TOXENV=docs DISABLE_COVERAGE=1
cache: pip
+v47.0.0
+-------
+
+* #2094: Setuptools now actively crashes under Python 2. Python 3.5 or later is required. Users of Python 2 should use ``setuptools<45``.
+* #1700: Document all supported keywords by migrating the ones from distutils.
+
+
v46.4.0
-------
Now generate the distribution. Although the PyPA is still working to
`provide a recommended tool <https://github.com/pypa/packaging-problems/issues/219>`_
-to build packages, the `pep517 package <https://pypi.org/project/pep517`_
+to build packages, the `pep517 package <https://pypi.org/project/pep517>`_
provides this functionality. To build the package::
$ pip install -q pep517
--- /dev/null
+``name``
+ A string specifying the name of the package.
+
+``version``
+ A string specifying the version number of the package.
+
+``description``
+ A string describing the package in a single line.
+
+``long_description``
+ A string providing a longer description of the package.
+
+``long_description_content_type``
+ A string specifying the content type is used for the ``long_description``
+ (e.g. ``text/markdown``)
+
+``author``
+ A string specifying the author of the package.
+
+``author_email``
+ A string specifying the email address of the package author.
+
+``maintainer``
+ A string specifying the name of the current maintainer, if different from
+ the author. Note that if the maintainer is provided, setuptools will use it
+ as the author in ``PKG-INFO``.
+
+``maintainer_email``
+ A string specifying the email address of the current maintainer, if
+ different from the author.
+
+``url``
+ A string specifying the URL for the package homepage.
+
+``download_url``
+ A string specifying the URL to download the package.
+
+``packages``
+ A list of strings specifying the packages that setuptools will manipulate.
+
+``py_modules``
+ A list of strings specifying the modules that setuptools will manipulate.
+
+``scripts``
+ A list of strings specifying the standalone script files to be built and
+ installed.
+
+``ext_package``
+ A string specifying the base package name for the extensions provided by
+ this package.
+
+``ext_modules``
+ A list of instances of ``setuptools.Extension`` providing the list of
+ Python extensions to be built.
+
+``classifiers``
+ A list of strings describing the categories for the package.
+
+``distclass``
+ A subclass of ``Distribution`` to use.
+
+``script_name``
+ A string specifying the name of the setup.py script -- defaults to
+ ``sys.argv[0]``
+
+``script_args``
+ A list of strings defining the arguments to supply to the setup script.
+
+``options``
+ A dictionary providing the default options for the setup script.
+
+``license``
+ A string specifying the license of the package.
+
+``keywords``
+ A list of strings or a comma-separated string providing descriptive
+ meta-data. See: `PEP 0314`_.
+
+.. _PEP 0314: https://www.python.org/dev/peps/pep-0314/
+
+``platforms``
+ A list of strings or comma-separated string.
+
+``cmdclass``
+ A dictionary providing a mapping of command names to ``Command``
+ subclasses.
+
+``data_files``
+
+ .. warning::
+ ``data_files`` is deprecated. It does not work with wheels, so it
+ should be avoided.
+
+ A list of strings specifying the data files to install.
+
+``package_dir``
+ A dictionary providing a mapping of package to directory names.
+
+``requires``
+
+ .. warning::
+ ``requires`` is superseded by ``install_requires`` and should not be used
+ anymore.
+
+``obsoletes``
+
+ .. warning::
+ ``obsoletes`` is currently ignored by ``pip``.
+
+ List of strings describing packages which this package renders obsolete,
+ meaning that the two projects should not be installed at the same time.
+
+ Version declarations can be supplied. Version numbers must be in the format
+ specified in Version specifiers (e.g. ``foo (<3.0)``).
+
+ This field may be followed by an environment marker after a semicolon (e.g.
+ ``foo; os_name == "posix"``)
+
+ The most common use of this field will be in case a project name changes,
+ e.g. Gorgon 2.3 gets subsumed into Torqued Python 1.0. When you install
+ Torqued Python, the Gorgon distribution should be removed.
+
+``provides``
+
+ .. warning::
+ ``provides`` is currently ignored by ``pip``.
+
+ List of strings describing package- and virtual package names contained
+ within this package.
+
+ A package may provide additional names, e.g. to indicate that multiple
+ projects have been bundled together. For instance, source distributions of
+ the ZODB project have historically included the transaction project, which
+ is now available as a separate distribution. Installing such a source
+ distribution satisfies requirements for both ZODB and transaction.
+
+ A package may also provide a “virtual” project name, which does not
+ correspond to any separately-distributed project: such a name might be used
+ to indicate an abstract capability which could be supplied by one of
+ multiple projects. E.g., multiple projects might supply RDBMS bindings for
+ use by a given ORM: each project might declare that it provides
+ ORM-bindings, allowing other projects to depend only on having at most one
+ of them installed.
+
+ A version declaration may be supplied and must follow the rules described in
+ Version specifiers. The distribution’s version number will be implied if
+ none is specified (e.g. ``foo (<3.0)``).
+
+ Each package may be followed by an environment marker after a semicolon
+ (e.g. ``foo; os_name == "posix"``).
+
+.. Below are setuptools keywords, above are distutils
+
+``include_package_data``
+ If set to ``True``, this tells ``setuptools`` to automatically include any
+ data files it finds inside your package directories that are specified by
+ your ``MANIFEST.in`` file. For more information, see the section on
+ :ref:`Including Data Files`.
+
+``exclude_package_data``
+ A dictionary mapping package names to lists of glob patterns that should
+ be *excluded* from your package directories. You can use this to trim back
+ any excess files included by ``include_package_data``. For a complete
+ description and examples, see the section on :ref:`Including Data Files`.
+
+``package_data``
+ A dictionary mapping package names to lists of glob patterns. For a
+ complete description and examples, see the section on :ref:`Including Data
+ Files`. You do not need to use this option if you are using
+ ``include_package_data``, unless you need to add e.g. files that are
+ generated by your setup script and build process. (And are therefore not
+ in source control or are files that you don't want to include in your
+ source distribution.)
+
+``zip_safe``
+ A boolean (True or False) flag specifying whether the project can be
+ safely installed and run from a zip file. If this argument is not
+ supplied, the ``bdist_egg`` command will have to analyze all of your
+ project's contents for possible problems each time it builds an egg.
+
+``install_requires``
+ A string or list of strings specifying what other distributions need to
+ be installed when this one is. See the section on :ref:`Declaring
+ Dependencies` for details and examples of the format of this argument.
+
+``entry_points``
+ A dictionary mapping entry point group names to strings or lists of strings
+ defining the entry points. Entry points are used to support dynamic
+ discovery of services or plugins provided by a project. See :ref:`Dynamic
+ Discovery of Services and Plugins` for details and examples of the format
+ of this argument. In addition, this keyword is used to support
+ :ref:`Automatic Script Creation`.
+
+``extras_require``
+ A dictionary mapping names of "extras" (optional features of your project)
+ to strings or lists of strings specifying what other distributions must be
+ installed to support those features. See the section on :ref:`Declaring
+ Dependencies` for details and examples of the format of this argument.
+
+``python_requires``
+ A string corresponding to a version specifier (as defined in PEP 440) for
+ the Python version, used to specify the Requires-Python defined in PEP 345.
+
+``setup_requires``
+
+ .. warning::
+ Using ``setup_requires`` is discouraged in favor of `PEP-518`_
+
+ A string or list of strings specifying what other distributions need to
+ be present in order for the *setup script* to run. ``setuptools`` will
+ attempt to obtain these (even going so far as to download them using
+ ``EasyInstall``) before processing the rest of the setup script or commands.
+ This argument is needed if you are using distutils extensions as part of
+ your build process; for example, extensions that process setup() arguments
+ and turn them into EGG-INFO metadata files.
+
+ (Note: projects listed in ``setup_requires`` will NOT be automatically
+ installed on the system where the setup script is being run. They are
+ simply downloaded to the ./.eggs directory if they're not locally available
+ already. If you want them to be installed, as well as being available
+ when the setup script is run, you should add them to ``install_requires``
+ **and** ``setup_requires``.)
+
+.. _PEP-518: http://www.python.org/dev/peps/pep-0518/
+
+``dependency_links``
+
+ .. warning::
+ ``dependency_links`` is deprecated. It is not supported anymore by pip.
+
+ A list of strings naming URLs to be searched when satisfying dependencies.
+ These links will be used if needed to install packages specified by
+ ``setup_requires`` or ``tests_require``. They will also be written into
+ the egg's metadata for use by tools like EasyInstall to use when installing
+ an ``.egg`` file.
+
+``namespace_packages``
+ A list of strings naming the project's "namespace packages". A namespace
+ package is a package that may be split across multiple project
+ distributions. For example, Zope 3's ``zope`` package is a namespace
+ package, because subpackages like ``zope.interface`` and ``zope.publisher``
+ may be distributed separately. The egg runtime system can automatically
+ merge such subpackages into a single parent package at runtime, as long
+ as you declare them in each project that contains any subpackages of the
+ namespace package, and as long as the namespace package's ``__init__.py``
+ does not contain any code other than a namespace declaration. See the
+ section on :ref:`Namespace Packages` for more information.
+
+``test_suite``
+ A string naming a ``unittest.TestCase`` subclass (or a package or module
+ containing one or more of them, or a method of such a subclass), or naming
+ a function that can be called with no arguments and returns a
+ ``unittest.TestSuite``. If the named suite is a module, and the module
+ has an ``additional_tests()`` function, it is called and the results are
+ added to the tests to be run. If the named suite is a package, any
+ submodules and subpackages are recursively added to the overall test suite.
+
+ Specifying this argument enables use of the :ref:`test` command to run the
+ specified test suite, e.g. via ``setup.py test``. See the section on the
+ :ref:`test` command below for more details.
+
+ New in 41.5.0: Deprecated the test command.
+
+``tests_require``
+ If your project's tests need one or more additional packages besides those
+ needed to install it, you can use this option to specify them. It should
+ be a string or list of strings specifying what other distributions need to
+ be present for the package's tests to run. When you run the ``test``
+ command, ``setuptools`` will attempt to obtain these (even going
+ so far as to download them using ``EasyInstall``). Note that these
+ required projects will *not* be installed on the system where the tests
+ are run, but only downloaded to the project's setup directory if they're
+ not already installed locally.
+
+ New in 41.5.0: Deprecated the test command.
+
+.. _test_loader:
+
+``test_loader``
+ If you would like to use a different way of finding tests to run than what
+ setuptools normally uses, you can specify a module name and class name in
+ this argument. The named class must be instantiable with no arguments, and
+ its instances must support the ``loadTestsFromNames()`` method as defined
+ in the Python ``unittest`` module's ``TestLoader`` class. Setuptools will
+ pass only one test "name" in the `names` argument: the value supplied for
+ the ``test_suite`` argument. The loader you specify may interpret this
+ string in any way it likes, as there are no restrictions on what may be
+ contained in a ``test_suite`` string.
+
+ The module name and class name must be separated by a ``:``. The default
+ value of this argument is ``"setuptools.command.test:ScanningLoader"``. If
+ you want to use the default ``unittest`` behavior, you can specify
+ ``"unittest:TestLoader"`` as your ``test_loader`` argument instead. This
+ will prevent automatic scanning of submodules and subpackages.
+
+ The module and class you specify here may be contained in another package,
+ as long as you use the ``tests_require`` option to ensure that the package
+ containing the loader class is available when the ``test`` command is run.
+
+ New in 41.5.0: Deprecated the test command.
+
+``eager_resources``
+ A list of strings naming resources that should be extracted together, if
+ any of them is needed, or if any C extensions included in the project are
+ imported. This argument is only useful if the project will be installed as
+ a zipfile, and there is a need to have all of the listed resources be
+ extracted to the filesystem *as a unit*. Resources listed here
+ should be '/'-separated paths, relative to the source root, so to list a
+ resource ``foo.png`` in package ``bar.baz``, you would include the string
+ ``bar/baz/foo.png`` in this argument.
+
+ If you only need to obtain resources one at a time, or you don't have any C
+ extensions that access other files in the project (such as data files or
+ shared libraries), you probably do NOT need this argument and shouldn't
+ mess with it. For more details on how this argument works, see the section
+ below on :ref:`Automatic Resource Extraction`.
+
+``use_2to3``
+ Convert the source code from Python 2 to Python 3 with 2to3 during the
+ build process. See :doc:`python3` for more details.
+
+``convert_2to3_doctests``
+ List of doctest source files that need to be converted with 2to3.
+ See :doc:`python3` for more details.
+
+``use_2to3_fixers``
+ A list of modules to search for additional fixers to be used during
+ the 2to3 conversion. See :doc:`python3` for more details.
+
+``use_2to3_exclude_fixers``
+ List of fixer names to be skipped.
+
+``project_urls``
+ An arbitrary map of URL names to hyperlinks, allowing more extensible
+ documentation of where various resources can be found than the simple
+ ``url`` and ``download_url`` options provide.
FooProject >= 1.2
Fizzy [foo, bar]
- PickyThing<1.6,>1.9,!=1.9.6,<2.0a0,==2.4c1
+ PickyThing>1.6,<=1.9,!=1.8.6
SomethingWhoseVersionIDontCareAbout
SomethingWithMarker[foo]>1.0;python_version<"2.7"
--- /dev/null
+:orphan:
+
+Python 2 Sunset
+===============
+
+Since January 2020 and the release of Setuptools 45, Python 2 is no longer
+supported by the most current release (`discussion
+<https://github.com/pypa/setuptools/issues/1458>`_). Setuptools as a project
+continues to support Python 2 with bugfixes and important features on
+Setuptools 44.x.
+
+By design, most users will be unaffected by this change. That's because
+Setuptools 45 declares its supported Python versions to exclude Python 2.7,
+and installers such as pip 9 or later will honor this declaration and prevent
+installation of Setuptools 45 or later in Python 2 environments.
+
+Users that do import any portion of Setuptools 45 or later on Python 2 are
+directed to this documentation to provide guidance on how to work around the
+issues.
+
+Workarounds
+-----------
+
+The best recommendation is to avoid Python 2 and move to Python 3 where
+possible. This project acknowledges that not all environments can drop Python
+2 support, so provides other options.
+
+In less common scenarios, later versions of Setuptools can be installed on
+unsupported Python versions. In these environments, the installer is advised
+to first install ``setuptools<45`` to "pin Setuptools" to a compatible
+version.
+
+- When using older versions of pip (before 9.0), the ``Requires-Python``
+ directive is not honored and invalid versions can be installed. Users are
+ advised first to upgrade pip and retry or to pin Setuptools. Use ``pip
+ --version`` to determine the version of pip.
+- When using ``easy_install``, ``Requires-Python`` is not honored and later
+ versions can be installed. In this case, users are advised to pin
+ Setuptools. This applies to ``setup.py install`` invocations as well, as
+ they use Setuptools under the hood.
+
+It's still not working
+----------------------
+
+If after trying the above steps, the Python environment still has incompatible
+versions of Setuptools installed, here are some things to try.
+
+1. Uninstall and reinstall Setuptools. Run ``pip uninstall -y setuptools`` for
+ the relevant environment. Repeat until there is no Setuptools installed.
+ Then ``pip install setuptools``.
+2. If possible, attempt to replicate the problem in a second environment
+ (virtual machine, friend's computer, etc). If the issue is isolated to just
+ one unique enviornment, first determine what is different about those
+ environments (or reinstall/reset the failing one to defaults).
+3. End users who are not themselves the maintainers for the package they are
+ trying to install should contact the support channels for the relevant
+ application. Please be considerate of those projects by searching for
+ existing issues and following the latest guidance before reaching out for
+ support. When filing an issue, be sure to give as much detail as possible
+ to help the maintainers understand what factors led to the issue after
+ following their recommended guidance.
+4. Reach out to your local support groups. There's a good chance someone
+ nearby has the expertise and willingness to help.
+5. If all else fails, `file this template
+ <https://github.com/pypa/setuptools/issues/new?assignees=&labels=Python+2&template=setuptools-warns-about-python-2-incompatibility.md&title=Incompatible+install+in+(summarize+your+environment)>`_
+ with Setuptools. Please complete the whole template, providing as much
+ detail about what factors led to the issue. Setuptools maintainers will
+ summarily close tickets filed without any meaningful detail or engagement
+ with the issue.
``setuptools``. All of them are optional; you do not have to supply them
unless you need the associated ``setuptools`` feature.
-``include_package_data``
- If set to ``True``, this tells ``setuptools`` to automatically include any
- data files it finds inside your package directories that are specified by
- your ``MANIFEST.in`` file. For more information, see the section below on
- `Including Data Files`_.
-
-``exclude_package_data``
- A dictionary mapping package names to lists of glob patterns that should
- be *excluded* from your package directories. You can use this to trim back
- any excess files included by ``include_package_data``. For a complete
- description and examples, see the section below on `Including Data Files`_.
-
-``package_data``
- A dictionary mapping package names to lists of glob patterns. For a
- complete description and examples, see the section below on `Including
- Data Files`_. You do not need to use this option if you are using
- ``include_package_data``, unless you need to add e.g. files that are
- generated by your setup script and build process. (And are therefore not
- in source control or are files that you don't want to include in your
- source distribution.)
-
-``zip_safe``
- A boolean (True or False) flag specifying whether the project can be
- safely installed and run from a zip file. If this argument is not
- supplied, the ``bdist_egg`` command will have to analyze all of your
- project's contents for possible problems each time it builds an egg.
-
-``install_requires``
- A string or list of strings specifying what other distributions need to
- be installed when this one is. See the section below on `Declaring
- Dependencies`_ for details and examples of the format of this argument.
-
-``entry_points``
- A dictionary mapping entry point group names to strings or lists of strings
- defining the entry points. Entry points are used to support dynamic
- discovery of services or plugins provided by a project. See `Dynamic
- Discovery of Services and Plugins`_ for details and examples of the format
- of this argument. In addition, this keyword is used to support `Automatic
- Script Creation`_.
-
-``extras_require``
- A dictionary mapping names of "extras" (optional features of your project)
- to strings or lists of strings specifying what other distributions must be
- installed to support those features. See the section below on `Declaring
- Dependencies`_ for details and examples of the format of this argument.
-
-``python_requires``
- A string corresponding to a version specifier (as defined in PEP 440) for
- the Python version, used to specify the Requires-Python defined in PEP 345.
-
-``setup_requires``
- A string or list of strings specifying what other distributions need to
- be present in order for the *setup script* to run. ``setuptools`` will
- attempt to obtain these (using pip if available) before processing the
- rest of the setup script or commands. This argument is needed if you
- are using distutils extensions as part of your build process; for
- example, extensions that process setup() arguments and turn them into
- EGG-INFO metadata files.
-
- (Note: projects listed in ``setup_requires`` will NOT be automatically
- installed on the system where the setup script is being run. They are
- simply downloaded to the ./.eggs directory if they're not locally available
- already. If you want them to be installed, as well as being available
- when the setup script is run, you should add them to ``install_requires``
- **and** ``setup_requires``.)
-
-``dependency_links``
- A list of strings naming URLs to be searched when satisfying dependencies.
- These links will be used if needed to install packages specified by
- ``setup_requires`` or ``tests_require``. They will also be written into
- the egg's metadata for use during install by tools that support them.
-
-``namespace_packages``
- A list of strings naming the project's "namespace packages". A namespace
- package is a package that may be split across multiple project
- distributions. For example, Zope 3's ``zope`` package is a namespace
- package, because subpackages like ``zope.interface`` and ``zope.publisher``
- may be distributed separately. The egg runtime system can automatically
- merge such subpackages into a single parent package at runtime, as long
- as you declare them in each project that contains any subpackages of the
- namespace package, and as long as the namespace package's ``__init__.py``
- does not contain any code other than a namespace declaration. See the
- section below on `Namespace Packages`_ for more information.
-
-``test_suite``
- A string naming a ``unittest.TestCase`` subclass (or a package or module
- containing one or more of them, or a method of such a subclass), or naming
- a function that can be called with no arguments and returns a
- ``unittest.TestSuite``. If the named suite is a module, and the module
- has an ``additional_tests()`` function, it is called and the results are
- added to the tests to be run. If the named suite is a package, any
- submodules and subpackages are recursively added to the overall test suite.
-
- Specifying this argument enables use of the `test`_ command to run the
- specified test suite, e.g. via ``setup.py test``. See the section on the
- `test`_ command below for more details.
-
- New in 41.5.0: Deprecated the test command.
-
-``tests_require``
- If your project's tests need one or more additional packages besides those
- needed to install it, you can use this option to specify them. It should
- be a string or list of strings specifying what other distributions need to
- be present for the package's tests to run. When you run the ``test``
- command, ``setuptools`` will attempt to obtain these (using pip if
- available). Note that these required projects will *not* be installed on
- the system where the tests are run, but only downloaded to the project's setup
- directory if they're not already installed locally.
-
- New in 41.5.0: Deprecated the test command.
-
-.. _test_loader:
-
-``test_loader``
- If you would like to use a different way of finding tests to run than what
- setuptools normally uses, you can specify a module name and class name in
- this argument. The named class must be instantiable with no arguments, and
- its instances must support the ``loadTestsFromNames()`` method as defined
- in the Python ``unittest`` module's ``TestLoader`` class. Setuptools will
- pass only one test "name" in the `names` argument: the value supplied for
- the ``test_suite`` argument. The loader you specify may interpret this
- string in any way it likes, as there are no restrictions on what may be
- contained in a ``test_suite`` string.
-
- The module name and class name must be separated by a ``:``. The default
- value of this argument is ``"setuptools.command.test:ScanningLoader"``. If
- you want to use the default ``unittest`` behavior, you can specify
- ``"unittest:TestLoader"`` as your ``test_loader`` argument instead. This
- will prevent automatic scanning of submodules and subpackages.
-
- The module and class you specify here may be contained in another package,
- as long as you use the ``tests_require`` option to ensure that the package
- containing the loader class is available when the ``test`` command is run.
-
- New in 41.5.0: Deprecated the test command.
-
-``eager_resources``
- A list of strings naming resources that should be extracted together, if
- any of them is needed, or if any C extensions included in the project are
- imported. This argument is only useful if the project will be installed as
- a zipfile, and there is a need to have all of the listed resources be
- extracted to the filesystem *as a unit*. Resources listed here
- should be "/"-separated paths, relative to the source root, so to list a
- resource ``foo.png`` in package ``bar.baz``, you would include the string
- ``bar/baz/foo.png`` in this argument.
-
- If you only need to obtain resources one at a time, or you don't have any C
- extensions that access other files in the project (such as data files or
- shared libraries), you probably do NOT need this argument and shouldn't
- mess with it. For more details on how this argument works, see the section
- below on `Automatic Resource Extraction`_.
-
-``use_2to3``
- Convert the source code from Python 2 to Python 3 with 2to3 during the
- build process. See :doc:`python3` for more details.
-
-``convert_2to3_doctests``
- List of doctest source files that need to be converted with 2to3.
- See :doc:`python3` for more details.
-
-``use_2to3_fixers``
- A list of modules to search for additional fixers to be used during
- the 2to3 conversion. See :doc:`python3` for more details.
-
-``project_urls``
- An arbitrary map of URL names to hyperlinks, allowing more extensible
- documentation of where various resources can be found than the simple
- ``url`` and ``download_url`` options provide.
+.. include:: keywords.txt
Using ``find_packages()``
.. _PEP 420: https://www.python.org/dev/peps/pep-0420/
+.. _Automatic Script Creation:
+
Automatic Script Creation
=========================
error if the ``.egg`` file has been renamed or is invoked via a symlink that
changes its base name.
+.. _Declaring Dependencies:
Declaring Dependencies
======================
.. _PEP 508: https://www.python.org/dev/peps/pep-0508/
+.. _Including Data Files:
+
Including Data Files
====================
Instead, the PyPA recommends that any data files you wish to be accessible at
run time be included in the package.
+.. _Automatic Resource Extraction:
Automatic Resource Extraction
-----------------------------
.. _Entry Points:
+.. _Dynamic Discovery of Services and Plugins:
+
Dynamic Discovery of Services and Plugins
-----------------------------------------
run. If the named suite is a package, any submodules and subpackages are
recursively added to the overall test suite. (Note: if your project specifies
a ``test_loader``, the rules for processing the chosen ``test_suite`` may
-differ; see the `test_loader`_ documentation for more details.)
+differ; see the :ref:`test_loader <test_loader>` documentation for more details.)
Note that many test systems including ``doctest`` support wrapping their
non-``unittest`` tests in ``TestSuite`` objects. So, if you are using a test
register_loader_type(object, NullProvider)
+def _parents(path):
+ """
+ yield all parents of path including path
+ """
+ last = None
+ while path != last:
+ yield path
+ last = path
+ path, _ = os.path.split(path)
+
+
class EggProvider(NullProvider):
"""Provider based on a virtual filesystem"""
self._setup_prefix()
def _setup_prefix(self):
- # we assume here that our metadata may be nested inside a "basket"
- # of multiple eggs; that's why we use module_path instead of .archive
- path = self.module_path
- old = None
- while path != old:
- if _is_egg_path(path):
- self.egg_name = os.path.basename(path)
- self.egg_info = os.path.join(path, 'EGG-INFO')
- self.egg_root = path
- break
- old = path
- path, base = os.path.split(path)
+ # Assume that metadata may be nested inside a "basket"
+ # of multiple eggs and use module_path instead of .archive.
+ eggs = filter(_is_egg_path, _parents(self.module_path))
+ egg = next(eggs, None)
+ egg and self._set_egg(egg)
+
+ def _set_egg(self, path):
+ self.egg_name = os.path.basename(path)
+ self.egg_info = os.path.join(path, 'EGG-INFO')
+ self.egg_root = path
class DefaultProvider(EggProvider):
msg = textwrap.dedent("""
- You are running Setuptools on Python 2, which is no longer
- supported and
- >>> SETUPTOOLS WILL STOP WORKING <<<
- in a subsequent release (no sooner than 2020-04-20).
- Please ensure you are installing
- Setuptools using pip 9.x or later or pin to `setuptools<45`
- in your environment.
- If you have done those things and are still encountering
- this message, please follow up at
- https://bit.ly/setuptools-py2-warning.
+ Encountered a version of Setuptools that no longer supports
+ this version of Python. Please head to
+ https://bit.ly/setuptools-py2-sunset for support.
""")
-pre = "Setuptools will stop working on Python 2\n"
+pre = "Setuptools no longer works on Python 2\n"
-sys.version_info < (3,) and warnings.warn(pre + "*" * 60 + msg + "*" * 60)
+if sys.version_info < (3,):
+ warnings.warn(pre + "*" * 60 + msg + "*" * 60)
+ raise SystemExit(32)
[metadata]
name = setuptools
-version = 46.4.0
+version = 47.0.0
description = Easily download, build, install, upgrade, and uninstall Python packages
author = Python Packaging Authority
author_email = distutils-sig@python.org
projects / platform / upstream / python-setuptools.git / commitdiff