././@PaxHeader 0000000 0000000 0000000 00000000034 00000000000 010212 x ustar 00 28 mtime=1692360483.5595517
setuptools-68.1.2/ 0000755 0001751 0000173 00000000000 14467657444 013457 5 ustar 00runner docker ././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/LICENSE 0000644 0001751 0000173 00000001777 14467657412 014473 0 ustar 00runner docker Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/MANIFEST.in 0000644 0001751 0000173 00000001210 14467657412 015202 0 ustar 00runner docker recursive-include setuptools *.py *.exe *.xml *.tmpl
recursive-include tests *.py
recursive-include setuptools/tests *.html
recursive-include docs *.py *.txt *.rst *.conf *.css *.css_t Makefile indexsidebar.html
recursive-include setuptools/_vendor *.py *.txt
recursive-include pkg_resources *.py *.txt
recursive-include pkg_resources/tests/data *
recursive-include tools *
recursive-include newsfragments *
include *.py
include *.rst
include MANIFEST.in
include LICENSE
include launcher.c
include msvc-build-launcher.cmd
include pytest.ini
include tox.ini
include setuptools/tests/config/setupcfg_examples.txt
global-exclude *.py[cod] __pycache__
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/NEWS.rst 0000644 0001751 0000173 00000677652 14467657412 015007 0 ustar 00runner docker v68.1.2
=======
Misc
----
- #4022, #4022
v68.1.1
=======
Bugfixes
--------
- Fix editable install finder handling of nested packages, by only handling 1
level of nesting and relying on ``importlib.machinery`` to find the remaining
modules based on the parent package path. (#4020)
v68.1.0
=======
Features
--------
- Removed code referencing bdist_wininst in install_scripts. (#3525)
- Promote ``pyproject.toml``'s ``[tool.setuptools]`` out of beta.
Note that some fields are still considered deprecated and/or obsolete,
and these might be removed in future versions (i.e., there is no guarantee
for long term support and backward compatibility on those fields). (#3962)
- Automatically add files listed in ``Extension.depends`` to sdists,
as long as they are contained in the project directory -- by :user:`RuRo` (#4000)
- Require Python 3.8 or later.
Bugfixes
--------
- Made imports in editable installs case-sensitive on case-insensitive filesystems -- by :user:`aganders3` (#3995)
- Use default encoding to create ``.pth`` files with ``editable_wheel``. (#4009)
- Detects (and complain about) ``scripts`` and ``gui-scripts`` set via ``setup.py``
when ``pyproject.toml`` does not include them in ``dynamic``. (#4012)
Misc
----
- #3833, #3960, #4001, #4007
v68.0.0
=======
Breaking Changes
----------------
* #3948: Removed verification for existing ``depends.txt`` file (deprecated since v0.5a4).
* #3948: Remove autofixing of broken ``.egg-info`` directories containing the ``-``
character in their base name (without suffix).
They should no longer be produced by sufficiently new versions of ``setuptools``
(warning introduced in 2005).
* #3948: Remove deprecated APIs in ``easy_install``: ``get_script_args``,
``get_script_header`` and ``get_writer``.
The direct usage of ``easy_install`` has been deprecated since v58.3.0,
and the warnings regarding these APIs predate that version.
* #3948: Removed ``egg_info.get_pkg_info_revision`` (deprecated since 2015).
* #3948: Removed ``setuptools.dist._get_unpatched`` (deprecated since 2016)
* #3948: Removed support for SVN in ``setuptools.package_index`` (deprecated since 2018).
* #3948: Removed support for invalid ``pyproject.toml`` files.
During the implementation of PEP 621, it was identified that some users were
producing invalid files. As a transitional measure, the validation was relaxed
for a few use cases. The grace period, however, came to an end.
Changes
-------
* #3760: Added symlink support to launcher for installed executables -- by :user:`eugene-sevostianov-sc`
* #3926: Updated vendored ``packaging`` version from 23.0 to 23.1 -- by :user:`MetRonnie`
* #3950: Implemented workaround for old versions of ``vswhere``, which miss the
``-requiresAny`` parameter, such as the ones distributed together with Visual Studio 2017 < 15.6.
* #3952: Changed ``DistutilsMetaFinder`` to skip ``spec_for_pip`` on Python >= 3.12.
* #3952: Removed ``_distutils_hack.remove_shim`` on Python >= 3.12
(since ``distutils`` was removed from the standard library,
``DistutilsMetaFinder`` cannot be disabled on Python >= 3.12).
Misc
----
* #3920: Add a link to deprecation warning in ``pkg_resources`` and improve
``stacklevel`` for better visibility.
v67.8.0
=======
Changes
-------
* #3128: In deprecated easy_install, reload and merge the pth file before saving.
Misc
----
* #3915: Adequate tests to the latest changes in ``virtualenv`` for Python 3.12.
v67.7.2
=======
Misc
----
* #3902: Fixed wrong URLs used in warnings and logs.
v67.7.1
=======
Misc
----
* #3898: Fixes setuptools.dist:invalid_unless_false when value is false don't raise error -- by :user:`jammarher`
v67.7.0
=======
Changes
-------
* #3849: Overhaul warning system for better visibility.
Documentation changes
---------------------
* #3859: Added a note about historical presence of ``wheel``
in ``build-system.requires``, in ``pyproject.toml``.
* #3893: Improved the documentation example regarding making a thin :pep:`517` in-tree
backend wrapper of ``setuptools.build_meta`` that is future-proof and supports
:pep:`660` hook too -- by :user:`webknjaz`.
Misc
----
* #3884: Add a ``stacklevel`` parameter to ``warnings.warn()`` to provide more information to the user.
-- by :user:`cclauss`
v67.6.1
=======
Misc
----
* #3865: Fixed ``_WouldIgnoreField`` warnings for ``scripts`` and ``gui_scripts``,
when ``entry-points`` is not listed in dynamic.
* #3875: Update code generated by ``validate-pyproject`` to use v0.12.2.
This should fix default license patterns when ``pyproject.toml`` is used.
v67.6.0
=======
Changes
-------
* #3804: Added caching for supported wheel tags.
* #3846: Added pruning heuristics to ``PackageFinder`` based on ``exclude``.
v67.5.1
=======
Misc
----
* #3836: Fixed interaction between ``setuptools``' package auto-discovery and
auto-generated ``htmlcov`` files.
Previously, the ``htmlcov`` name was ignored when searching for single-file
modules, however the correct behaviour is to ignore it when searching for
packages (since it is supposed to be a directory, see `coverage config`_)
-- by :user:`yukihiko-shinoda`.
.. _coverage config: https://coverage.readthedocs.io/en/stable/config.html#html-directory
* #3838: Improved error messages for ``pyproject.toml`` validations.
* #3839: Fixed ``pkg_resources`` errors caused when parsing metadata of packages that
are already installed but do not conform with PEP 440.
v67.5.0
=======
Changes
-------
* #3843: Although pkg_resources has been discouraged for use, some projects still consider pkg_resources viable for usage. This change makes it clear that pkg_resources should not be used, emitting a DeprecationWarning when imported.
v67.4.0
=======
Changes
-------
* #3832: Update vendored ``importlib-metadata`` (to 6.0.0) and
``importlib-resources`` (to 5.10.2)
v67.3.3
=======
Misc
----
* #3820: Restore quoted ``#include`` argument to ``has_function``.
v67.3.2
=======
Misc
----
* #3827: Improve deprecation warning message on ``pkg_resources.declare_namespace``
to display package name.
v67.3.1
=======
Misc
----
* #3823: Fixes ``egg_info`` code path triggered during integration with ``pip``.
v67.3.0
=======
Deprecations
------------
* #3434: Added deprecation warning for ``pkg_resources.declare_namespace``.
Users that wish to implement namespace packages, are recommended to follow the
practice described in PEP 420 and omit the ``__init__.py`` file entirely.
Changes
-------
* #3792: Reduced usage of ``pkg_resources`` in ``setuptools`` via internal
restructuring and refactoring.
Misc
----
* #3822: Added debugging tips for "editable mode" and update related docs.
Instead of using a custom exception to display the help message to the user,
``setuptools`` will now use a warning and re-raise the original exception.
* #3822: Added clarification about ``editable_wheel`` and ``dist_info`` CLI commands:
they should not be called directly with ``python setup.py ...``.
Instead they are reserved for internal use of ``setuptools`` (effectively as "private" commands).
Users are recommended to rely on build backend APIs (:pep:`517` and :pep:`660`)
exposed by ``setuptools.build_meta``.
v67.2.0
=======
Changes
-------
* #3809: Merge with distutils@8c3c3d29, including fix for ``sysconfig.get_python_inc()`` (pypa/distutils#178), fix for segfault on MinGW (pypa/distutils#196), and better ``has_function`` support (pypa/distutils#195, #3648).
v67.1.0
=======
Changes
-------
* #3795: Ensured that ``__file__`` is an absolute path when executing ``setup.py`` as
part of ``setuptools.build_meta``.
Misc
----
* #3798: Updated validations for ``pyproject.toml`` using ``validate-pyproject==0.12.1``
to allow stub packages (:pep:`561`) to be listed in ``tool.setuptools.packages``
and ``tool.setuptools.package-dir``.
v67.0.0
=======
Breaking Changes
----------------
* #3741: Removed patching of ``distutils._msvccompiler.gen_lib_options``
for compatibility with Numpy < 1.11.2 -- by :user:`mgorny`
* #3790: Bump vendored version of :pypi:`packaging` to 23.0
(:pypi:`pyparsing` is no longer required and was removed).
As a consequence, users will experience a more strict parsing of requirements.
Specifications that don't comply with :pep:`440` and :pep:`508` will result
in build errors.
v66.1.1
=======
Misc
----
* #3782: Fixed problem with ``file`` directive in ``tool.setuptools.dynamic``
(``pyproject.toml``) when value is a simple string instead of list.
v66.1.0
=======
Changes
-------
* #3685: Fix improper usage of deprecated/removed ``pkgutil`` APIs in Python 3.12+.
* #3779: Files referenced by ``file:`` in ``setup.cfg`` and by ``project.readme.file``,
``project.license.file`` or ``tool.setuptools.dynamic.*.file`` in
``pyproject.toml`` are now automatically included in the generated sdists.
Misc
----
* #3776: Added note about using the ``--pep-517`` flag with ``pip`` to workaround
``InvalidVersion`` errors for packages that are already installed in the system.
v66.0.0
=======
Breaking Changes
----------------
* #2497: Support for PEP 440 non-conforming versions has been removed. Environments containing packages with non-conforming versions may fail or the packages may not be recognized.
Changes
-------
* #3769: Replace 'appdirs' with 'platformdirs'.
v65.7.0
=======
Changes
-------
* #3594: Added ``htmlcov`` to FlatLayoutModuleFinder.DEFAULT_EXCLUDE -- by :user:`demianbrecht`
* #3667: Added a human-readable error description when ``.egg-info`` directory is not writeable -- by :user:`droodev`
Misc
----
* #3713: Fixed incomplete ``getattr`` statement that caused problems when accessing
undefined attribute.
v65.6.3
=======
Misc
----
* #3709: Fix condition to patch ``distutils.dist.log`` to only apply when using
``distutils`` from the stdlib.
v65.6.2
=======
No significant changes.
v65.6.1
=======
Documentation changes
---------------------
* #3689: Documented that ``distutils.cfg`` might be ignored unless
``SETUPTOOLS_USE_DISTUTILS=stdlib``.
Misc
----
* #3678: Improve clib builds reproducibility by sorting sources -- by :user:`danigm`
* #3684: Improved exception/traceback when invalid entry-points are specified.
* #3690: Fixed logging errors: 'underlying buffer has been detached' (issue #1631).
* #3693: Merge pypa/distutils@3e9d47e with compatibility fix for distutils.log.Log.
* #3695, #3697, #3698, #3699: Changed minor text details (spelling, spaces ...)
* #3696: Removed unnecessary ``coding: utf-8`` annotations
* #3704: Fixed temporary build directories interference with auto-discovery.
v65.6.0
=======
Changes
-------
* #3674: Sync with pypa/distutils@e0787fa, including pypa/distutils#183 updating distutils to use the Python logging framework.
v65.5.1
=======
Misc
----
* #3638: Drop a test dependency on the ``mock`` package, always use :external+python:py:mod:`unittest.mock` -- by :user:`hroncok`
* #3659: Fixed REDoS vector in package_index.
v65.5.0
=======
Changes
-------
* #3624: Fixed editable install for multi-module/no-package ``src``-layout projects.
* #3626: Minor refactorings to support distutils using stdlib logging module.
Documentation changes
---------------------
* #3419: Updated the example version numbers to be compliant with PEP-440 on the "Specifying Your Project’s Version" page of the user guide.
Misc
----
* #3569: Improved information about conflicting entries in the current working directory
and editable install (in documentation and as an informational warning).
* #3576: Updated version of ``validate_pyproject``.
v65.4.1
=======
Misc
----
* #3613: Fixed encoding errors in ``expand.StaticModule`` when system default encoding doesn't match expectations for source files.
* #3617: Merge with pypa/distutils@6852b20 including fix for pypa/distutils#181.
v65.4.0
=======
Changes
-------
* #3609: Merge with pypa/distutils@d82d926 including support for DIST_EXTRA_CONFIG in pypa/distutils#177.
v65.3.0
=======
Changes
-------
* #3547: Stop ``ConfigDiscovery.analyse_name`` from splatting the ``Distribution.name`` attribute -- by :user:`jeamland`
Documentation changes
---------------------
* #3554: Changed requires to requests in the pyproject.toml example in the :doc:`Dependency management section of the Quickstart guide ` -- by :user:`mfbutner`
Misc
----
* #3561: Fixed accidental name matching in editable hooks.
v65.2.0
=======
Changes
-------
* #3553: Sync with pypa/distutils@22b9bcf, including fixed cross-compiling support and removing deprecation warning per pypa/distutils#169.
v65.1.1
=======
Misc
----
* #3551: Avoided circular imports in meta path finder for editable installs when a
missing module has the same name as its parent.
v65.1.0
=======
Changes
-------
* #3536: Remove monkeypatching of msvc9compiler.
Documentation changes
---------------------
* #3538: Corrected documentation on how to use the ``legacy-editable`` mode.
v65.0.2
=======
Misc
----
* #3505: Restored distutils msvccompiler and msvc9compiler modules and marked as deprecated (pypa/distutils@c802880).
v65.0.1
=======
Documentation changes
---------------------
* #3529: Added clarification to :doc:`/userguide/quickstart` about support
to ``setup.py``.
Misc
----
* #3526: Fixed backward compatibility of editable installs and custom ``build_ext``
commands inheriting directly from ``distutils``.
* #3528: Fixed ``buid_meta.prepare_metadata_for_build_wheel`` when
given ``metadata_directory`` is ``"."``.
v65.0.0
=======
Breaking Changes
----------------
* #3505: Removed 'msvccompiler' and 'msvc9compiler' modules from distutils.
* #3521: Remove bdist_msi and bdist_wininst commands, which have been deprecated since Python 3.9. Use older Setuptools for these behaviors if needed.
Documentation changes
---------------------
* #3519: Changed the note in ``keywords`` documentation regarding editable installations
to specify which ``setuptools`` version require a minimal ``setup.py`` file or not.
v64.0.3
=======
Misc
----
* #3515: Fixed "inline" file copying for editable installations and
optional extensions.
* #3517: Fixed ``editable_wheel`` to ensure other commands are finalized before using
them. This should prevent errors with plugins trying to use different commands
or reinitializing them.
* #3517: Augmented filter to prevent transient/temporary source files from being
considered ``package_data`` or ``data_files``.
v64.0.2
=======
Misc
----
* #3506: Suppress errors in custom ``build_py`` implementations when running editable
installs in favor of a warning indicating what is the most appropriate
migration path.
This is a *transitional* measure. Errors might be raised in future versions of
``setuptools``.
* #3512: Added capability of handling namespace packages created
accidentally/purposefully via discovery configuration during editable installs.
This should emulate the behaviour of a non-editable installation.
v64.0.1
=======
Misc
----
* #3497: Fixed ``editable_wheel`` for legacy namespaces.
* #3502: Fixed issue with editable install and single module distributions.
* #3503: Added filter to ignore external ``.egg-info`` files in manifest.
Some plugins might rely on the fact that the ``.egg-info`` directory is
produced inside the project dir, which may not be the case in editable installs
(the ``.egg-info`` directory is produced inside the metadata directory given by
the build frontend via PEP 660 hooks).
v64.0.0
=======
Deprecations
------------
* #3380: Passing some types of parameters via ``--global-option`` to setuptools PEP 517/PEP 660 backend
is now considered deprecated. The user can pass the same arbitrary parameter
via ``--build-option`` (``--global-option`` is now reserved for flags like
``--verbose`` or ``--quiet``).
Both ``--build-option`` and ``--global-option`` are supported as a **transitional** effort (a.k.a. "escape hatch").
In the future a proper list of allowed ``config_settings`` may be created.
Breaking Changes
----------------
* #3265: Added implementation for *editable install* hooks (PEP 660).
By default the users will experience a *lenient* behavior which prioritises
the ability of the users of changing the distributed packages (e.g. adding new
files or removing old ones).
But they can also opt into a *strict* mode, which will try to replicate as much
as possible the behavior of the package as if it would be normally installed by
end users. The *strict* editable installation is not able to detect if files
are added or removed from the project (a new installation is required).
This implementation might also affect plugins and customizations that assume
certain ``build`` subcommands don't run during editable installs or that they
always copy files to the temporary build directory.
.. important::
The *editable* aspect of the *editable install* supported this implementation
is restricted to the Python modules contained in the distributed package.
Changes in binary extensions (e.g. C/C++), entry-point definitions,
dependencies, metadata, datafiles, etc may require a new installation.
Changes
-------
* #3380: Improved the handling of the ``config_settings`` parameter in both PEP 517 and
PEP 660 interfaces:
- It is possible now to pass both ``--global-option`` and ``--build-option``.
As discussed in #1928, arbitrary arguments passed via ``--global-option``
should be placed before the name of the setuptools' internal command, while
``--build-option`` should come after.
- Users can pass ``editable-mode=strict`` to select a strict behaviour for the
editable installation.
* #3392: Exposed ``get_output_mapping()`` from ``build_py`` and ``build_ext``
subcommands. This interface is reserved for the use of ``setuptools``
Extensions and third part packages are explicitly disallowed to calling it.
However, any implementation overwriting ``build_py`` or ``build_ext`` are
required to honour this interface.
* #3412: Added ability of collecting source files from custom build sub-commands to
``sdist``. This allows plugins and customization scripts to automatically
add required source files in the source distribution.
* #3414: Users can *temporarily* specify an environment variable
``SETUPTOOLS_ENABLE_FEATURES=legacy-editable`` as a escape hatch for the
:pep:`660` behavior. This setting is **transitional** and may be removed in the
future.
* #3484: Added *transient* ``compat`` mode to editable installs.
This more will be temporarily available (to facilitate the transition period)
for those that want to emulate the behavior of the ``develop`` command
(in terms of what is added to ``sys.path``).
This mode is provided "as is", with limited support, and will be removed in
future versions of ``setuptools``.
Documentation changes
---------------------
* #3414: Updated :doc:`Development Mode ` to reflect on the
implementation of :pep:`660`.
v63.4.3
=======
Misc
----
* #3496: Update to pypa/distutils@b65aa40 including more robust support for library/include dir handling in msvccompiler (pypa/distutils#153) and test suite improvements.
v63.4.2
=======
Misc
----
* #3453: Bump vendored version of :pypi:`pyparsing` to 3.0.9.
* #3481: Add warning for potential ``install_requires`` and ``extras_require``
misconfiguration in ``setup.cfg``
* #3487: Modified ``pyproject.toml`` validation exception handling to
make relevant debugging information easier to spot.
v63.4.1
=======
Misc
----
* #3482: Sync with pypa/distutils@274758f1c02048d295efdbc13d2f88d9923547f8, restoring compatibility shim in bdist.format_commands.
v63.4.0
=======
Changes
-------
* #2971: ``upload_docs`` command is deprecated once again.
Documentation changes
---------------------
* #3443: Installed ``sphinx-hoverxref`` extension to show tooltips on internal an external references.
-- by :user:`humitos`
* #3444: Installed ``sphinx-notfound-page`` extension to generate nice 404 pages.
-- by :user:`humitos`
Misc
----
* #3480: Merge with pypa/distutils@c397f4c
v63.3.0
=======
Changes
-------
* #3475: Merge with pypa/distutils@129480b, including substantial delinting and cleanup, some refactoring around compiler logic, better messaging in cygwincompiler (pypa/distutils#161).
v63.2.0
=======
Changes
-------
* #3395: Included a performance optimization: ``setuptools.build_meta`` no longer tries
to :func:`compile` the setup script code before :func:`exec`-ing it.
Misc
----
* #3435: Corrected issue in macOS framework builds on Python 3.9 not installed by homebrew (pypa/distutils#158).
v63.1.0
=======
Changes
-------
* #3430: Merge with pypa/distutils@152c13d including pypa/distutils#155 (improved compatibility for editable installs on homebrew Python 3.9), pypa/distutils#150 (better handling of runtime_library_dirs on cygwin), and pypa/distutils#151 (remove warnings for namespace packages).
v63.0.0
=======
Breaking Changes
----------------
* #3421: Drop setuptools' support for installing an entrypoint extra requirements at load time:
- the functionality has been broken since v60.8.0.
- the mechanism to do so is deprecated (``fetch_build_eggs``).
- that use case (e.g. a custom command class entrypoint) is covered by making sure the necessary build requirements are declared.
Documentation changes
---------------------
* #3305: Updated the example pyproject.toml -- by :user:`jacalata`
* #3394: This updates the documentation for the ``file_finders`` hook so that
the logging recommendation aligns with the suggestion to not use
``distutils`` directly.
* #3397: Fix reference for ``keywords`` to point to the Core Metadata Specification
instead of PEP 314 (the live standard is kept always up-to-date and
consolidates several PEPs together in a single document).
* #3402: Reordered the User Guide's Table of Contents -- by :user:`codeandfire`
v62.6.0
=======
Changes
-------
* #3253: Enabled using ``file:`` for requirements in setup.cfg -- by :user:`akx`
(this feature is currently considered to be in **beta** stage).
* #3255: Enabled using ``file:`` for dependencies and optional-dependencies in pyproject.toml -- by :user:`akx`
(this feature is currently considered to be in **beta** stage).
* #3391: Updated ``attr:`` to also extract simple constants with type annotations -- by :user:`karlotness`
v62.5.0
=======
Changes
-------
* #3347: Changed warnings and documentation notes about *experimental* aspect of ``pyproject.toml`` configuration:
now ``[project]`` is a fully supported configuration interface, but the ``[tool.setuptools]`` table
and sub-tables are still considered to be in **beta** stage.
* #3383: In _distutils_hack, suppress/undo the use of local distutils when select tests are imported in CPython.
Documentation changes
---------------------
* #3368: Added documentation page about extension modules -- by :user:`mkoeppe`
* #3371: Moved documentation from ``/userguide/commands`` to ``/depracted/commands``.
This change was motived by the fact that running ``python setup.py`` directly is
considered a deprecated practice.
* #3372: Consolidated sections about ``sdist`` contents and ``MANIFEST.in`` into a single page.
Added a simple ``MANIFEST.in`` example.
* #3373: Moved remarks about using :pypi:`Cython` to the newly created page for
extension modules.
* #3374: Added clarification that using ``python setup.py egg_info`` commands to
manage project versions is only supported in a *transitional* basis, and
that eventually ``egg_info`` will be deprecated.
Reorganized sections with tips for managing versions.
* #3378: Updated ``Quickstart`` docs to make it easier to follow for beginners.
Misc
----
* #3385: Modules used to parse and evaluate configuration from ``pyproject.toml`` files are
intended for internal use only and that not part of the public API.
v62.4.0
=======
Changes
-------
* #3256: Added setuptools.command.build command to match distutils.command.build -- by :user:`isuruf`
* #3366: Merge with pypa/distutils@75ed79d including reformat using black, fix for Cygwin support (pypa/distutils#139), and improved support for cross compiling (pypa/distutils#144 and pypa/distutils#145).
Documentation changes
---------------------
* #3355: Changes to the User Guide's Entry Points page -- by :user:`codeandfire`
* #3361: Further minor corrections to the Entry Points page -- by :user:`codeandfire`
* #3363: Rework some documentation pages to de-emphasize ``distutils`` and the history
of packaging in the Python ecosystem. The focus of these changes is to make the
documentation easier to read for new users.
* #3364: Update documentation about dependency management, removing mention to
the deprecated ``dependency_links`` and adding some small improvements.
* #3367: Extracted text about automatic resource extraction and the zip-safe flag
from ``userguide/miscellaneous`` to ``deprecated/resource_extraction`` and
``deprecated/zip_safe``.
Extracted text about additional metadata files from
``userguide/miscellaneous`` into the existing ``userguide/extension``
document.
Updated ``userguide/extension`` to better reflect the status of the
setuptools project.
Removed ``userguide/functionalities_rewrite`` (a virtually empty part of the
docs).
v62.3.4
=======
Documentation changes
---------------------
* #3349: Fixed two small issues preventing docs from building locally -- by :user:`codeandfire`
* #3350: Added note explaining ``package_data`` glob pattern matching for dotfiles -- by :user:`comabrewer`
* #3358: Clarify the role of the ``package_dir`` configuration.
Misc
----
* #3354: Improve clarity in warning about unlisted namespace packages.
v62.3.3
=======
Documentation changes
---------------------
* #3331: Replaced single backticks with double ones in ``CHANGES.rst`` -- by :user:`codeandfire`
* #3332: Fixed grammar/typos, modified example directory trees for src-layout and flat-layout -- by :user:`codeandfire`
* #3335: Changes to code snippets and other examples in the Data Files page of the User Guide -- by :user:`codeandfire`
Misc
----
* #3336: Modified ``test_setup_install_includes_dependencies`` to work with custom ``PYTHONPATH`` –- by :user:`hroncok`
v62.3.2
=======
Misc
----
* #3328: Include a first line summary to some of the existing multi-line warnings.
v62.3.1
=======
Misc
----
* #3320: Fixed typo which causes ``namespace_packages`` to raise an error instead of
warning.
v62.3.0
=======
Deprecations
------------
* #3262: Formally added deprecation messages for ``namespace_packages``.
The methodology that uses ``pkg_resources`` and ``namespace_packages`` for
creating namespaces was already discouraged by the :doc:`setuptools docs
` and the
:doc:`Python Packaging User Guide `,
therefore this change just make the deprecation more official.
Users can consider migrating to native/implicit namespaces (as introduced in
:pep:`420`).
* #3308: Relying on ``include_package_data`` to ensure sub-packages are automatically
added to the build wheel distribution (as "data") is now considered a
deprecated practice.
This behaviour was controversial and caused inconsistencies (#3260).
Instead, projects are encouraged to properly configure ``packages`` or use
discovery tools. General information can be found in :doc:`userguide/package_discovery`.
Changes
-------
* #1806: Allowed recursive globs (``**``) in ``package_data``. -- by :user:`nullableVoidPtr`
* #3206: Fixed behaviour when both ``install_requires`` (in ``setup.py``) and
``dependencies`` (in ``pyproject.toml``) are specified.
The configuration in ``pyproject.toml`` will take precedence over ``setup.py``
(in accordance with PEP 621). A warning was added to inform users.
Documentation changes
---------------------
* #3307: Added introduction to references/keywords.
Added deprecation tags to test kwargs.
Moved userguide/keywords to deprecated section.
Clarified in deprecated doc what keywords came from distutils and which were added or changed by setuptools.
Misc
----
* #3274: Updated version of vendored ``pyparsing`` to 3.0.8 to avoid problems with
upcoming deprecation in Python 3.11.
* #3292: Added warning about incompatibility with old versions of
``importlib-metadata``.
v62.2.0
=======
Changes
-------
* #3299: Optional metadata fields are now truly optional. Includes merge with pypa/distutils@a7cfb56 per pypa/distutils#138.
Misc
----
* #3282: Added CI cache for ``setup.cfg`` examples used when testing ``setuptools.config``.
v62.1.0
=======
Changes
-------
* #3258: Merge pypa/distutils@5229dad46b.
Misc
----
* #3249: Simplified ``package_dir`` obtained via auto-discovery.
v62.0.0
=======
Breaking Changes
----------------
* #3151: Made ``setup.py develop --user`` install to the user site packages directory even if it is disabled in the current interpreter.
Changes
-------
* #3153: When resolving requirements use both canonical and normalized names -- by :user:`ldaniluk`
* #3167: Honor unix file mode in ZipFile when installing wheel via ``install_as_egg`` -- by :user:`delijati`
Misc
----
* #3088: Fixed duplicated tag with the ``dist-info`` command.
* #3247: Fixed problem preventing ``readme`` specified as dynamic in ``pyproject.toml``
from being dynamically specified in ``setup.py``.
v61.3.1
=======
Misc
----
* #3233: Included missing test file ``setupcfg_examples.txt`` in ``sdist``.
* #3233: Added script that allows developers to download ``setupcfg_examples.txt`` prior to
running tests. By caching these files it should be possible to run the test suite
offline.
v61.3.0
=======
Changes
-------
* #3229: Disabled automatic download of ``trove-classifiers`` to facilitate reproducibility.
Misc
----
* #3229: Updated ``pyproject.toml`` validation via ``validate-pyproject`` v0.7.1.
* #3229: New internal tool made available for updating the code responsible for
the validation of ``pyproject.toml``.
This tool can be executed via ``tox -e generate-validation-code``.
v61.2.0
=======
Changes
-------
* #3215: Ignored a subgroup of invalid ``pyproject.toml`` files that use the ``[project]``
table to specify only ``requires-python`` (**transitional**).
.. warning::
Please note that future releases of setuptools will halt the build process
if a ``pyproject.toml`` file that does not match doc:`the PyPA Specification
` is given.
* #3215: Updated ``pyproject.toml`` validation, as generated by ``validate-pyproject==0.6.1``.
* #3218: Prevented builds from erroring if the project specifies metadata via
``pyproject.toml``, but uses other files (e.g. ``setup.py``) to complement it,
without setting ``dynamic`` properly.
.. important::
This is a **transitional** behaviour.
Future releases of ``setuptools`` may simply ignore externally set metadata
not backed by ``dynamic`` or even halt the build with an error.
* #3224: Merge changes from pypa/distutils@e1d5c9b1f6
Documentation changes
---------------------
* #3217: Fixed typo in ``pyproject.toml`` example in Quickstart -- by :user:`pablo-cardenas`.
Misc
----
* #3223: Fixed missing requirements with environment markers when
``optional-dependencies`` is set in ``pyproject.toml``.
v61.1.1
=======
Misc
----
* #3212: Fixed missing dependencies when running ``setup.py install``.
Note that calling ``setup.py install`` directly is still deprecated and
will be removed in future versions of ``setuptools``.
Please check the release notes for :ref:`setup_install_deprecation_note`.
v61.1.0
=======
Deprecations
------------
* #3206: Changed ``setuptools.convert_path`` to an internal function that is not exposed
as part of setuptools API.
Future releases of ``setuptools`` are likely to remove this function.
Changes
-------
* #3202: Changed behaviour of auto-discovery to not explicitly expand ``package_dir``
for flat-layouts and to not use relative paths starting with ``./``.
* #3203: Prevented ``pyproject.toml`` parsing from overwriting
``dist.include_package_data`` explicitly set in ``setup.py`` with default
value.
* #3208: Added a warning for non existing files listed with the ``file`` directive in
``setup.cfg`` and ``pyproject.toml``.
* #3208: Added a default value for dynamic ``classifiers`` in ``pyproject.toml`` when
files are missing and errors being ignored.
* #3211: Disabled auto-discovery when distribution class has a ``configuration``
attribute (e.g. when the ``setup.py`` script contains ``setup(...,
configuration=...)``). This is done to ensure extension-only packages created
with ``numpy.distutils.misc_util.Configuration`` are not broken by the safe
guard
behaviour to avoid accidental multiple top-level packages in a flat-layout.
.. note::
Users that don't set ``packages``, ``py_modules``, or ``configuration`` are
still likely to observe the auto-discovery behavior, which may halt the
build if the project contains multiple directories and/or multiple Python
files directly under the project root.
To disable auto-discovery please explicitly set either ``packages`` or
``py_modules``. Alternatively you can also configure :ref:`custom-discovery`.
v61.0.0
=======
Deprecations
------------
* #3068: Deprecated ``setuptools.config.read_configuration``,
``setuptools.config.parse_configuration`` and other functions or classes
from ``setuptools.config``.
Users that still need to parse and process configuration from ``setup.cfg`` can
import a direct replacement from ``setuptools.config.setupcfg``, however this
module is transitional and might be removed in the future
(the ``setup.cfg`` configuration format itself is likely to be deprecated in the future).
Breaking Changes
----------------
* #2894: If you purposefully want to create an *"empty distribution"*, please be aware
that some Python files (or general folders) might be automatically detected and
included.
Projects that currently don't specify both ``packages`` and ``py_modules`` in their
configuration and contain extra folders or Python files (not meant for distribution),
might see these files being included in the wheel archive or even experience
the build to fail.
You can check details about the automatic discovery (and how to configure a
different behaviour) in :doc:`/userguide/package_discovery`.
* #3067: If the file ``pyproject.toml`` exists and it includes project
metadata/config (via ``[project]`` table or ``[tool.setuptools]``),
a series of new behaviors that are not backward compatible may take place:
- The default value of ``include_package_data`` will be considered to be ``True``.
- Setuptools will attempt to validate the ``pyproject.toml`` file according
to PEP 621 specification.
- The values specified in ``pyproject.toml`` will take precedence over those
specified in ``setup.cfg`` or ``setup.py``.
Changes
-------
* #2887: **[EXPERIMENTAL]** Added automatic discovery for ``py_modules`` and ``packages``
-- by :user:`abravalheri`.
Setuptools will try to find these values assuming that the package uses either
the *src-layout* (a ``src`` directory containing all the packages or modules),
the *flat-layout* (package directories directly under the project root),
or the *single-module* approach (an isolated Python file, directly under
the project root).
The automatic discovery will also respect layouts that are explicitly
configured using the ``package_dir`` option.
For backward-compatibility, this behavior will be observed **only if both**
``py_modules`` **and** ``packages`` **are not set**.
(**Note**: specifying ``ext_modules`` might also prevent auto-discover from
taking place)
If setuptools detects modules or packages that are not supposed to be in the
distribution, please manually set ``py_modules`` and ``packages`` in your
``setup.cfg`` or ``setup.py`` file.
If you are using a *flat-layout*, you can also consider switching to
*src-layout*.
* #2887: **[EXPERIMENTAL]** Added automatic configuration for the ``name`` metadata
-- by :user:`abravalheri`.
Setuptools will adopt the name of the top-level package (or module in the case
of single-module distributions), **only when** ``name`` **is not explicitly
provided**.
Please note that it is not possible to automatically derive a single name when
the distribution consists of multiple top-level packages or modules.
* #3066: Added vendored dependencies for :pypi:`tomli`, :pypi:`validate-pyproject`.
These dependencies are used to read ``pyproject.toml`` files and validate them.
* #3067: **[EXPERIMENTAL]** When using ``pyproject.toml`` metadata,
the default value of ``include_package_data`` is changed to ``True``.
* #3068: **[EXPERIMENTAL]** Add support for ``pyproject.toml`` configuration
(as introduced by :pep:`621`). Configuration parameters not covered by
standards are handled in the ``[tool.setuptools]`` sub-table.
In the future, existing ``setup.cfg`` configuration
may be automatically converted into the ``pyproject.toml`` equivalent before taking effect
(as proposed in #1688). Meanwhile users can use automated tools like
:pypi:`ini2toml` to help in the transition.
Please note that the legacy backend is not guaranteed to work with
``pyproject.toml`` configuration.
-- by :user:`abravalheri`
* #3125: Implicit namespaces (as introduced in :pep:`420`) are now considered by default
during :doc:`package discovery `, when
``setuptools`` configuration and project metadata are added to the
``pyproject.toml`` file.
To disable this behaviour, use ``namespaces = False`` when explicitly setting
the ``[tool.setuptools.packages.find]`` section in ``pyproject.toml``.
This change is backwards compatible and does not affect the behaviour of
configuration done in ``setup.cfg`` or ``setup.py``.
* #3152: **[EXPERIMENTAL]** Added support for ``attr:`` and ``cmdclass`` configurations
in ``setup.cfg`` and ``pyproject.toml`` when ``package_dir`` is implicitly
found via auto-discovery.
* #3178: Postponed importing ``ctypes`` when hiding files on Windows.
This helps to prevent errors in systems that might not have ``libffi`` installed.
* #3179: Merge with pypa/distutils@267dbd25ac
Documentation changes
---------------------
* #3172: Added initial documentation about configuring ``setuptools`` via ``pyproject.toml``
(using standard project metadata).
Misc
----
* #3065: Refactored ``setuptools.config`` by separating configuration parsing (specific
to the configuration file format, e.g. ``setup.cfg``) and post-processing
(which includes directives such as ``file:`` that can be used across different
configuration formats).
v60.10.0
========
Changes
-------
* #2971: Deprecated upload_docs command, to be removed in the future.
* #3137: Use samefile from stdlib, supported on Windows since Python 3.2.
* #3170: Adopt nspektr (vendored) to implement Distribution._install_dependencies.
Documentation changes
---------------------
* #3144: Added documentation on using console_scripts from setup.py, which was previously only shown in setup.cfg -- by :user:`xhlulu`
* #3148: Added clarifications about ``MANIFEST.in``, that include links to PyPUG docs
and more prominent mentions to using a revision control system plugin as an
alternative.
* #3148: Removed mention to ``pkg_resources`` as the recommended way of accessing data
files, in favour of importlib.resources.
Additionally more emphasis was put on the fact that *package data files* reside
**inside** the *package directory* (and therefore should be *read-only*).
Misc
----
* #3120: Added workaround for intermittent failures of backend tests on PyPy.
These tests now are marked with `XFAIL
`_, instead of erroring
out directly.
* #3124: Improved configuration for :pypi:`rst-linker` (extension used to build the
changelog).
* #3133: Enhanced isolation of tests using virtual environments - PYTHONPATH is not leaking to spawned subprocesses -- by :user:`befeleme`
* #3147: Added options to provide a pre-built ``setuptools`` wheel or sdist for being
used during tests with virtual environments.
Paths for these pre-built distribution files can now be set via the environment
variables: ``PRE_BUILT_SETUPTOOLS_SDIST`` and ``PRE_BUILT_SETUPTOOLS_WHEEL``.
v60.9.3
=======
Misc
----
* #3093: Repaired automated release process.
v60.9.2
=======
Misc
----
* #3035: When loading distutils from the vendored copy, rewrite ``__name__`` to ensure consistent importing from inside and out.
v60.9.1
=======
Misc
----
* #3102: Prevent vendored importlib_metadata from loading distributions from older importlib_metadata.
* #3103: Fixed issue where string-based entry points would be omitted.
* #3107: Bump importlib_metadata to 4.11.1 addressing issue with parsing requirements in egg-info as found in PyPy.
v60.9.0
=======
Changes
-------
* #2876: In the build backend, allow single config settings to be supplied.
* #2993: Removed workaround in distutils hack for get-pip now that pypa/get-pip#137 is closed.
* #3085: Setuptools no longer relies on ``pkg_resources`` for entry point handling.
* #3098: Bump vendored packaging to 21.3.
* Removed bootstrap script.
.. warning:: Users trying to install the unmaintained :pypi:`pathlib` backport
from PyPI/``sdist``/source code may find problems when using ``setuptools >= 60.9.0``.
This happens because during the installation, the unmaintained
implementation of ``pathlib`` is loaded and may cause compatibility problems
(it does not expose the same public API defined in the Python standard library).
Whenever possible users should avoid declaring ``pathlib`` as a dependency.
An alternative is to pre-build a wheel for ``pathlib`` using a separated
virtual environment with an older version of setuptools and install the
library directly from the pre-built wheel.
v60.8.2
=======
Misc
----
* #3091: Make ``concurrent.futures`` import lazy in vendored ``more_itertools``
package to a avoid importing threading as a side effect (which caused
`gevent/gevent#1865 `__).
-- by :user:`maciejp-ro`
v60.8.1
=======
Misc
----
* #3084: When vendoring jaraco packages, ensure the namespace package is converted to a simple package to support zip importer.
v60.8.0
=======
Changes
-------
* #3085: Setuptools now vendors importlib_resources and importlib_metadata and jaraco.text. Setuptools no longer relies on pkg_resources for ensure_directory nor parse_requirements.
v60.7.1
=======
Misc
----
* #3072: Remove lorem_ipsum from jaraco.text when vendored.
v60.7.0
=======
Changes
-------
* #3061: Vendored jaraco.text and use line processing from that library in pkg_resources.
Misc
----
* #3070: Avoid AttributeError in easy_install.create_home_path when sysconfig.get_config_vars values are not strings.
v60.6.0
=======
Changes
-------
* #3043: Merge with pypa/distutils@bb018f1ac3 including consolidated behavior in sysconfig.get_platform (pypa/distutils#104).
* #3057: Don't include optional ``Home-page`` in metadata if no ``url`` is specified. -- by :user:`cdce8p`
* #3062: Merge with pypa/distutils@b53a824ec3 including improved support for lib directories on non-x64 Windows builds.
Documentation changes
---------------------
* #2897: Added documentation about wrapping ``setuptools.build_meta`` in a in-tree
custom backend. This is a :pep:`517`-compliant way of dynamically specifying
build dependencies (e.g. when platform, OS and other markers are not enough).
-- by :user:`abravalheri`
* #3034: Replaced occurrences of the defunct distutils-sig mailing list with pointers
to GitHub Discussions.
-- by :user:`ashemedai`
* #3056: The documentation has stopped suggesting to add ``wheel`` to
:pep:`517` requirements -- by :user:`webknjaz`
Misc
----
* #3054: Used Py3 syntax ``super().__init__()`` -- by :user:`imba-tjd`
v60.5.4
=======
Misc
----
* #3009: Remove filtering of distutils warnings.
* #3031: Suppress distutils replacement when building or testing CPython.
v60.5.3
=======
Misc
----
* #3026: Honor sysconfig variables in easy_install.
v60.5.2
=======
Misc
----
* #2993: In _distutils_hack, for get-pip, simulate existence of setuptools.
v60.5.1
=======
Misc
----
* #2918: Correct support for Python 3 native loaders.
v60.5.0
=======
Changes
-------
* #2990: Set the ``.origin`` attribute of the ``distutils`` module to the module's ``__file__``.
v60.4.0
=======
Changes
-------
* #2839: Removed ``requires`` sorting when installing wheels as an egg dir.
* #2953: Fixed a bug that easy install incorrectly parsed Python 3.10 version string.
* #3006: Fixed startup performance issue of Python interpreter due to imports of
costly modules in ``_distutils_hack`` -- by :user:`tiran`
Documentation changes
---------------------
* #2674: Added link to additional resources on packaging in Quickstart guide
* #3008: "In-tree" Sphinx extension for "favicons" replaced with ``sphinx-favicon``.
* #3008: SVG images (logo, banners, ...) optimised with the help of the ``scour``
package.
Misc
----
* #2862: Added integration tests that focus on building and installing some packages in
the Python ecosystem via ``pip`` -- by :user:`abravalheri`
* #2952: Modified "vendoring" logic to keep license files.
* #2968: Improved isolation for some tests that where inadvertently using the project
root for builds, and therefore creating directories (e.g. ``build``, ``dist``,
``*.egg-info``) that could interfere with the outcome of other tests
-- by :user:`abravalheri`.
* #2968: Introduced new test fixtures ``venv``, ``venv_without_setuptools``,
``bare_venv`` that rely on the ``jaraco.envs`` package.
These new test fixtures were also used to remove the (currently problematic)
dependency on the ``pytest_virtualenv`` plugin.
* #2968: Removed ``tmp_src`` test fixture. Previously this fixture was copying all the
files and folders under the project root, including the ``.git`` directory,
which is error prone and increases testing time.
Since ``tmp_src`` was used to populate virtual environments (installing the
version of ``setuptools`` under test via the source tree), it was replaced by
the new ``setuptools_sdist`` and ``setuptools_wheel`` fixtures (that are build
only once per session testing and can be shared between all the workers for
read-only usage).
v60.3.1
=======
Misc
----
* #3002: Suppress AttributeError when detecting get-pip.
v60.3.0
=======
Changes
-------
* #2993: In _distutils_hack, bypass the distutils exception for pip when get-pip is being invoked, because it imports setuptools.
Misc
----
* #2989: Merge with pypa/distutils@788cc159. Includes fix for config vars missing from sysconfig.
v60.2.0
=======
Changes
-------
* #2974: Setuptools now relies on the Python logging infrastructure to log messages. Instead of using ``distutils.log.*``, use ``logging.getLogger(name).*``.
* #2987: Sync with pypa/distutils@2def21c5d74fdd2fe7996ee4030ac145a9d751bd, including fix for missing get_versions attribute (#2969), more reliance on sysconfig from stdlib.
Misc
----
* #2962: Avoid attempting to use local distutils when the presiding version of Setuptools on the path doesn't have one.
* #2983: Restore 'add_shim' as the way to invoke the hook. Avoids compatibility issues between different versions of Setuptools with the distutils local implementation.
v60.1.1
=======
Misc
----
* #2980: Bypass distutils loader when setuptools module is no longer available on sys.path.
v60.1.0
=======
Changes
-------
* #2958: In distutils_hack, only add the metadata finder once. In ensure_local_distutils, rely on a context manager for reliable manipulation.
* #2963: Merge with pypa/distutils@a5af364910. Includes revisited fix for pypa/distutils#15 and improved MinGW/Cygwin support from pypa/distutils#77.
v60.0.5
=======
Misc
----
* #2960: Install schemes fall back to default scheme for headers.
v60.0.4
=======
Misc
----
* #2954: Merge with pypa/distutils@eba2bcd310. Adds platsubdir to config vars available for substitution.
v60.0.3
=======
Misc
----
* #2940: Avoid KeyError in distutils hack when pip is imported during ensurepip.
v60.0.2
=======
Misc
----
* #2938: Select 'posix_user' for the scheme unless falling back to stdlib, then use 'unix_user'.
v60.0.1
=======
Misc
----
* #2944: Add support for extended install schemes in easy_install.
v60.0.0
=======
Breaking Changes
----------------
* #2896: Setuptools once again makes its local copy of distutils the default. To override, set SETUPTOOLS_USE_DISTUTILS=stdlib.
v59.8.0
=======
Changes
-------
* #2935: Merge pypa/distutils@460b59f0e68dba17e2465e8dd421bbc14b994d1f.
v59.7.0
=======
Changes
-------
* #2930: Require Python 3.7
v59.6.0
=======
Changes
-------
* #2925: Merge with pypa/distutils@92082ee42c including introduction of deprecation warning on Version classes.
v59.5.0
=======
Changes
-------
* #2914: Merge with pypa/distutils@8f2df0bf6.
v59.4.0
=======
Changes
-------
* #2893: Restore deprecated support for newlines in the Summary field.
v59.3.0
=======
Changes
-------
* #2902: Merge with pypa/distutils@85db7a41242.
Misc
----
* #2906: In ensure_local_distutils, re-use DistutilsMetaFinder to load the module. Avoids race conditions when _distutils_system_mod is employed.
v59.2.0
=======
Changes
-------
* #2875: Introduce changes from pypa/distutils@514e9d0, including support for overrides from Debian and pkgsrc, unlocking the possibility of making SETUPTOOLS_USE_DISTUTILS=local the default again.
v59.1.1
=======
Misc
----
* #2885: Fixed errors when encountering LegacyVersions.
v59.1.0
=======
Changes
-------
* #2497: Update packaging to 21.2.
* #2877: Back out deprecation of setup_requires and replace instead by a deprecation of setuptools.installer and fetch_build_egg. Now setup_requires is still supported when installed as part of a PEP 517 build, but is deprecated when an unsatisfied requirement is encountered.
* #2879: Bump packaging to 21.2.
Documentation changes
---------------------
* #2867: PNG/ICO images replaced with SVG in the docs.
* #2867: Added support to SVG "favicons" via "in-tree" Sphinx extension.
v59.0.1
=======
Misc
----
* #2880: Removed URL requirement for ``pytest-virtualenv`` in ``setup.cfg``.
PyPI rejects packages with dependencies external to itself.
Instead the test dependency was overwritten via ``tox.ini``
v59.0.0
=======
Deprecations
------------
* #2856: Support for custom commands that inherit directly from ``distutils`` is
**deprecated**. Users should extend classes provided by setuptools instead.
Breaking Changes
----------------
* #2870: Started failing on invalid inline description with line breaks :class:`ValueError` -- by :user:`webknjaz`
Changes
-------
* #2698: Exposed exception classes from ``distutils.errors`` via ``setuptools.errors``.
* #2866: Incorporate changes from pypa/distutils@f1b0a2b.
Documentation changes
---------------------
* #2227: Added sphinx theme customisations to display the new logo in the sidebar and
use its colours as "accent" in the documentation -- by :user:`abravalheri`
* #2227: Added new setuptools logo, including editable files and artwork documentation
-- by :user:`abravalheri`
* #2698: Added mentions to ``setuptools.errors`` as a way of handling custom command
errors.
* #2698: Added instructions to migrate from ``distutils.commands`` and
``distutils.errors`` in the porting guide.
* #2871: Added a note to the docs that it is possible to install
``setup.py``-less projects in editable mode with :doc:`pip v21.1+
`, only having ``setup.cfg`` and ``pyproject.toml`` in
project root -- by :user:`webknjaz`
v58.5.3
=======
Misc
----
* #2849: Add fallback for custom ``build_py`` commands inheriting directly from
:mod:`distutils`, while still handling ``include_package_data=True`` for
``sdist``.
v58.5.2
=======
Misc
----
* #2847: Suppress 'setup.py install' warning under bdist_wheel.
v58.5.1
=======
Misc
----
* #2846: Move PkgResourcesDeprecationWarning above implicitly-called function so that it's in the namespace when version warnings are generated in an environment that contains them.
v58.5.0
=======
Changes
-------
* #1461: Fix inconsistency with ``include_package_data`` and ``packages_data`` in sdist
by replacing the loop breaking mechanism between the ``sdist`` and
``egg_info`` commands -- by :user:`abravalheri`
v58.4.0
=======
Changes
-------
* #2497: Officially deprecated PEP 440 non-compliant versions.
Documentation changes
---------------------
* #2832: Removed the deprecated ``data_files`` option from the example in the
declarative configuration docs -- by :user:`abravalheri`
* #2832: Change type of ``data_files`` option from ``dict`` to ``section`` in
declarative configuration docs (to match previous example) -- by
:user:`abravalheri`
.. _setup_install_deprecation_note:
v58.3.0
=======
Changes
-------
* #917: ``setup.py install`` and ``easy_install`` commands are now officially deprecated. Use other standards-based installers (like pip) and builders (like build). Workloads reliant on this behavior should pin to this major version of Setuptools. See `Why you shouldn't invoke setup.py directly `_ for more background.
* #1988: Deprecated the ``bdist_rpm`` command. Binary packages should be built as wheels instead.
-- by :user:`hugovk`
* #2785: Replace ``configparser``'s ``readfp`` with ``read_file``, deprecated since Python 3.2.
-- by :user:`hugovk`
* #2823: Officially deprecated support for ``setup_requires``. Users are encouraged instead to migrate to PEP 518 ``build-system.requires`` in ``pyproject.toml``. Users reliant on ``setup_requires`` should consider pinning to this major version to avoid disruption.
Misc
----
* #2762: Changed codecov.yml to configure the threshold to be lower
-- by :user:`tanvimoharir`
v58.2.0
=======
Changes
-------
* #2757: Add windows arm64 launchers for scripts generated by easy_install.
* #2800: Added ``--owner`` and ``--group`` options to the ``sdist`` command,
for specifying file ownership within the produced tarball (similarly
to the corresponding distutils ``sdist`` options).
Documentation changes
---------------------
* #2792: Document how the legacy and non-legacy versions are compared, and reference to the PEP 440 scheme.
v58.1.0
=======
Changes
-------
* #2796: Merge with pypa/distutils@02e9f65ab0
v58.0.4
=======
Misc
----
* #2773: Retain case in setup.cfg during sdist.
v58.0.3
=======
Misc
----
* #2777: Build does not fail fast when ``use_2to3`` is supplied but set to a false value.
v58.0.2
=======
Misc
----
* #2769: Build now fails fast when ``use_2to3`` is supplied.
v58.0.1
=======
Misc
----
* #2765: In Distribution.finalize_options, suppress known removed entry points to avoid issues with older Setuptools.
v58.0.0
=======
Breaking Changes
----------------
* #2086: Removed support for 2to3 during builds. Projects should port to a unified codebase or pin to an older version of Setuptools using PEP 518 build-requires.
Documentation changes
---------------------
* #2746: add python_requires example
v57.5.0
=======
Changes
-------
* #2712: Added implicit globbing support for ``[options.data_files]`` values.
Documentation changes
---------------------
* #2737: fix various syntax and style errors in code snippets in docs
v57.4.0
=======
Changes
-------
* #2722: Added support for ``SETUPTOOLS_EXT_SUFFIX`` environment variable to override the suffix normally detected from the ``sysconfig`` module.
v57.3.0
=======
Changes
-------
* #2465: Documentation is now published using the Furo theme.
v57.2.0
=======
Changes
-------
* #2724: Added detection of Windows ARM64 build environments using the ``VSCMD_ARG_TGT_ARCH`` environment variable.
v57.1.0
=======
Changes
-------
* #2692: Globs are now sorted in 'license_files' restoring reproducibility by eliminating variance from disk order.
* #2714: Update to distutils at pypa/distutils@e2627b7.
* #2715: Removed reliance on deprecated ssl.match_hostname by removing the ssl support. Now any index operations rely on the native SSL implementation.
Documentation changes
---------------------
* #2604: Revamped the backward/cross tool compatibility section to remove
some confusion.
Add some examples and the version since when ``entry_points`` are
supported in declarative configuration.
Tried to make the reading flow a bit leaner, gather some information
that were a bit dispersed.
v57.0.0
=======
Breaking Changes
----------------
* #2645: License files excluded via the ``MANIFEST.in`` but matched by either
the ``license_file`` (deprecated) or ``license_files`` options,
will be nevertheless included in the source distribution. - by :user:`cdce8p`
Changes
-------
* #2628: Write long description in message payload of PKG-INFO file. - by :user:`cdce8p`
* #2645: Added ``License-File`` (multiple) to the output package metadata.
The field will contain the path of a license file, matched by the
``license_file`` (deprecated) and ``license_files`` options,
relative to ``.dist-info``. - by :user:`cdce8p`
* #2678: Moved Setuptools' own entry points into declarative config.
* #2680: Vendored :pypi:`more_itertools` for Setuptools.
* #2681: Setuptools own setup.py no longer declares setup_requires, but instead expects wheel to be installed as declared by pyproject.toml.
Misc
----
* #2650: Updated the docs build tooling to support the latest version of
Towncrier and show the previews of not-yet-released setuptools versions
in the changelog -- :user:`webknjaz`
v56.2.0
=======
Changes
-------
* #2640: Fixed handling of multiline license strings. - by :user:`cdce8p`
* #2641: Setuptools will now always try to use the latest supported
metadata version for ``PKG-INFO``. - by :user:`cdce8p`
v56.1.0
=======
Changes
-------
* #2653: Incorporated assorted changes from pypa/distutils.
* #2657: Adopted docs from distutils.
* #2663: Added Visual Studio Express 2017 support -- by :user:`dofuuz`
Misc
----
* #2644: Fixed ``DeprecationWarning`` due to ``threading.Thread.setDaemon`` in tests -- by :user:`tirkarthi`
* #2654: Made the changelog generator compatible
with Towncrier >= 19.9 -- :user:`webknjaz`
* #2664: Relax the deprecation message in the distutils hack.
v56.0.0
=======
Deprecations
------------
* #2620: The ``license_file`` option is now marked as deprecated.
Use ``license_files`` instead. -- by :user:`cdce8p`
Breaking Changes
----------------
* #2620: If neither ``license_file`` nor ``license_files`` is specified, the ``sdist``
option will now auto-include files that match the following patterns:
``LICEN[CS]E*``, ``COPYING*``, ``NOTICE*``, ``AUTHORS*``.
This matches the behavior of ``bdist_wheel``. -- by :user:`cdce8p`
Changes
-------
* #2620: The ``license_file`` and ``license_files`` options now support glob patterns. -- by :user:`cdce8p`
* #2632: Implemented ``VendorImporter.find_spec()`` method to get rid
of ``ImportWarning`` that Python 3.10 emits when only the old-style
importer hooks are present -- by :user:`webknjaz`
Documentation changes
---------------------
* #2620: Added documentation for the ``license_files`` option. -- by :user:`cdce8p`
v55.0.0
=======
Breaking Changes
----------------
* #2566: Remove the deprecated ``bdist_wininst`` command. Binary packages should be built as wheels instead. -- by :user:`hroncok`
v54.2.0
=======
Changes
-------
* #2608: Added informative error message to PEP 517 build failures owing to
an empty ``setup.py`` -- by :user:`layday`
v54.1.3
=======
No significant changes.
v54.1.2
=======
Misc
----
* #2595: Reduced scope of dash deprecation warning to Setuptools/distutils only -- by :user:`melissa-kun-li`
v54.1.1
=======
Documentation changes
---------------------
* #2584: Added ``sphinx-inline-tabs`` extension to allow for comparison of ``setup.py`` and its equivalent ``setup.cfg`` -- by :user:`amy-lei`
Misc
----
* #2592: Made option keys in the ``[metadata]`` section of ``setup.cfg`` case-sensitive. Users having
uppercase option spellings will get a warning suggesting to make them to lowercase
-- by :user:`melissa-kun-li`
v54.1.0
=======
Changes
-------
* #1608: Removed the conversion of dashes to underscores in the :code:`extras_require` and :code:`data_files` of :code:`setup.cfg` to support the usage of dashes. Method will warn users when they use a dash-separated key which in the future will only allow an underscore. Note: the method performs the dash to underscore conversion to preserve compatibility, but future versions will no longer support it -- by :user:`melissa-kun-li`
v54.0.0
=======
Breaking Changes
----------------
* #2582: Simplified build-from-source story by providing bootstrapping metadata in a separate egg-info directory. Build requirements no longer include setuptools itself. Sdist once again includes the pyproject.toml. Project can no longer be installed from source on pip 19.x, but install from source is still supported on pip < 19 and pip >= 20 and install from wheel is still supported with pip >= 9.
Changes
-------
* #1932: Handled :code:`AttributeError` by raising :code:`DistutilsSetupError` in :code:`dist.check_specifier()` when specifier is not a string -- by :user:`melissa-kun-li`
* #2570: Correctly parse cmdclass in setup.cfg.
Documentation changes
---------------------
* #2553: Added userguide example for markers in extras_require -- by :user:`pwoolvett`
v53.1.0
=======
Changes
-------
* #1937: Preserved case-sensitivity of keys in setup.cfg so that entry point names are case-sensitive. Changed sensitivity of configparser. NOTE: Any projects relying on case-insensitivity will need to adapt to accept the original case as published. -- by :user:`melissa-kun-li`
* #2573: Fixed error in uploading a Sphinx doc with the :code:`upload_docs` command. An html builder will be used.
Note: :code:`upload_docs` is deprecated for PyPi, but is supported for other sites -- by :user:`melissa-kun-li`
v53.0.0
=======
Breaking Changes
----------------
* #1527: Removed bootstrap script. Now Setuptools requires pip or another pep517-compliant builder such as 'build' to build. Now Setuptools can be installed from Github main branch.
v52.0.0
=======
Breaking Changes
----------------
* #2537: Remove fallback support for fetch_build_eggs using easy_install. Now pip is required for setup_requires to succeed.
* #2544: Removed 'easy_install' top-level model (runpy entry point) and 'easy_install' console script.
* #2545: Removed support for eggsecutables.
Changes
-------
* #2459: Tests now run in parallel via pytest-xdist, completing in about half the time. Special thanks to :user:`webknjaz` for hard work implementing test isolation. To run without parallelization, disable the plugin with ``tox -- -p no:xdist``.
v51.3.3
=======
Misc
----
* #2539: Fix AttributeError in Description validation.
v51.3.2
=======
Misc
----
* #1390: Validation of Description field now is more lenient, emitting a warning and mangling the value to be valid (replacing newlines with spaces).
v51.3.1
=======
Misc
----
* #2536: Reverted tag deduplication handling.
v51.3.0
=======
Changes
-------
* #1390: Newlines in metadata description/Summary now trigger a ValueError.
* #2481: Define ``create_module()`` and ``exec_module()`` methods in ``VendorImporter``
to get rid of ``ImportWarning`` -- by :user:`hroncok`
* #2489: ``pkg_resources`` behavior for zipimport now matches the regular behavior, and finds
``.egg-info`` (previously would only find ``.dist-info``) -- by :user:`thatch`
* #2529: Fixed an issue where version tags may be added multiple times
v51.2.0
=======
Changes
-------
* #2493: Use importlib.import_module() rather than the deprecated loader.load_module()
in pkg_resources namespace declaration -- by :user:`encukou`
Documentation changes
---------------------
* #2525: Fix typo in the document page about entry point. -- by :user:`jtr109`
Misc
----
* #2534: Avoid hitting network during test_easy_install.
v51.1.2
=======
Misc
----
* #2505: Disable inclusion of package data as it causes 'tests' to be included as data.
v51.1.1
=======
Misc
----
* #2534: Avoid hitting network during test_virtualenv.test_test_command.
v51.1.0
=======
Changes
-------
* #2486: Project adopts jaraco/skeleton for shared package maintenance.
Misc
----
* #2477: Restore inclusion of rst files in sdist.
* #2484: Setuptools has replaced the master branch with the main branch.
* #2485: Fixed failing test when pip 20.3+ is present.
-- by :user:`yan12125`
* #2487: Fix tests with pytest 6.2
-- by :user:`yan12125`
v51.0.0
=======
Breaking Changes
----------------
* #2435: Require Python 3.6 or later.
Documentation changes
---------------------
* #2430: Fixed inconsistent RST title nesting levels caused by #2399
-- by :user:`webknjaz`
* #2430: Fixed a typo in Sphinx docs that made docs dev section disappear
as a result of PR #2426 -- by :user:`webknjaz`
Misc
----
* #2471: Removed the tests that guarantee that the vendored dependencies can be built by distutils.
v50.3.2
=======
Documentation changes
---------------------
* #2394: Extended towncrier news template to include change note categories.
This allows to see what types of changes a given version introduces
-- by :user:`webknjaz`
* #2427: Started enforcing strict syntax and reference validation
in the Sphinx docs -- by :user:`webknjaz`
* #2428: Removed redundant Sphinx ``Makefile`` support -- by :user:`webknjaz`
Misc
----
* #2401: Enabled test results reporting in AppVeyor CI
-- by :user:`webknjaz`
* #2420: Replace Python 3.9.0 beta with 3.9.0 final on GitHub Actions.
* #2421: Python 3.9 Trove classifier got added to the dist metadata
-- by :user:`webknjaz`
v50.3.1
=======
Documentation changes
---------------------
* #2093: Finalized doc revamp.
* #2097: doc: simplify index and group deprecated files
* #2102: doc overhaul step 2: break main doc into multiple sections
* #2111: doc overhaul step 3: update userguide
* #2395: Added a ``:user:`` role to Sphinx config -- by :user:`webknjaz`
* #2395: Added an illustrative explanation about the change notes to fragments dir -- by :user:`webknjaz`
Misc
----
* #2379: Travis CI test suite now tests against PPC64.
* #2413: Suppress EOF errors (and other exceptions) when importing lib2to3.
v50.3.0
=======
Changes
-------
* #2368: In distutils, restore support for monkeypatched CCompiler.spawn per pypa/distutils#15.
v50.2.0
=======
Changes
-------
* #2355: When pip is imported as part of a build, leave distutils patched.
* #2380: There are some setuptools specific changes in the
``setuptools.command.bdist_rpm`` module that are no longer needed, because
they are part of the ``bdist_rpm`` module in distutils in Python
3.5.0. Therefore, code was removed from ``setuptools.command.bdist_rpm``.
v50.1.0
=======
Changes
-------
* #2350: Setuptools reverts using the included distutils by default. Platform maintainers and system integrators and others are *strongly* encouraged to set ``SETUPTOOLS_USE_DISTUTILS=local`` to help identify and work through the reported issues with distutils adoption, mainly to file issues and pull requests with pypa/distutils such that distutils performs as needed across every supported environment.
v50.0.3
=======
Misc
----
* #2363: Restore link_libpython support on Python 3.7 and earlier (see pypa/distutils#9).
v50.0.2
=======
Misc
----
* #2352: In distutils hack, use absolute import rather than relative to avoid bpo-30876.
v50.0.1
=======
Misc
----
* #2357: Restored Python 3.5 support in distutils.util for missing ``subprocess._optim_args_from_interpreter_flags``.
* #2358: Restored AIX support on Python 3.8 and earlier.
* #2361: Add Python 3.10 support to _distutils_hack. Get the 'Loader' abstract class
from importlib.abc rather than importlib.util.abc (alias removed in Python
3.10).
v50.0.0
=======
Breaking Changes
----------------
* #2232: Once again, Setuptools overrides the stdlib distutils on import. For environments or invocations where this behavior is undesirable, users are provided with a temporary escape hatch. If the environment variable ``SETUPTOOLS_USE_DISTUTILS`` is set to ``stdlib``, Setuptools will fall back to the legacy behavior. Use of this escape hatch is discouraged, but it is provided to ease the transition while proper fixes for edge cases can be addressed.
Changes
-------
* #2334: In MSVC module, refine text in error message.
v49.6.0
=======
Changes
-------
* #2129: In pkg_resources, no longer detect any pathname ending in .egg as a Python egg. Now the path must be an unpacked egg or a zip file.
v49.5.0
=======
Changes
-------
* #2306: When running as a PEP 517 backend, setuptools does not try to install
``setup_requires`` itself. They are reported as build requirements for the
frontend to install.
v49.4.0
=======
Changes
-------
* #2310: Updated vendored packaging version to 20.4.
v49.3.2
=======
Documentation changes
---------------------
* #2300: Improve the ``safe_version`` function documentation
Misc
----
* #2297: Once again, in stubs prefer exec_module to the deprecated load_module.
v49.3.1
=======
Changes
-------
* #2316: Removed warning when ``distutils`` is imported before ``setuptools`` when ``distutils`` replacement is not enabled.
v49.3.0
=======
Changes
-------
* #2259: Setuptools now provides a .pth file (except for editable installs of setuptools) to the target environment to ensure that when enabled, the setuptools-provided distutils is preferred before setuptools has been imported (and even if setuptools is never imported). Honors the SETUPTOOLS_USE_DISTUTILS environment variable.
v49.2.1
=======
Misc
----
* #2257: Fixed two flaws in distutils._msvccompiler.MSVCCompiler.spawn.
v49.2.0
=======
Changes
-------
* #2230: Now warn the user when setuptools is imported after distutils modules have been loaded (exempting PyPy for 3.6), directing the users of packages to import setuptools first.
v49.1.3
=======
Misc
----
* #2212: (Distutils) Allow spawn to accept environment. Avoid monkey-patching global state.
* #2249: Fix extension loading technique in stubs.
v49.1.2
=======
Changes
-------
* #2232: In preparation for re-enabling a local copy of distutils, Setuptools now honors an environment variable, SETUPTOOLS_USE_DISTUTILS. If set to 'stdlib' (current default), distutils will be used from the standard library. If set to 'local' (default in a imminent backward-incompatible release), the local copy of distutils will be used.
v49.1.1
=======
Misc
----
* #2094: Removed pkg_resources.py2_warn module, which is no longer reachable.
v49.0.1
=======
Misc
----
* #2228: Applied fix for pypa/distutils#3, restoring expectation that spawn will raise a DistutilsExecError when attempting to execute a missing file.
v49.1.0
=======
Changes
-------
* #2228: Disabled distutils adoption for now while emergent issues are addressed.
v49.0.0
=======
Breaking Changes
----------------
* #2165: Setuptools no longer installs a site.py file during easy_install or develop installs. As a result, .eggs on PYTHONPATH will no longer take precedence over other packages on sys.path. If this issue affects your production environment, please reach out to the maintainers at #2165.
Changes
-------
* #2137: Removed (private) pkg_resources.RequirementParseError, now replaced by packaging.requirements.InvalidRequirement. Kept the name for compatibility, but users should catch InvalidRequirement instead.
* #2180: Update vendored packaging in pkg_resources to 19.2.
Misc
----
* #2199: Fix exception causes all over the codebase by using ``raise new_exception from old_exception``
v48.0.0
=======
Breaking Changes
----------------
* #2143: Setuptools adopts distutils from the Python 3.9 standard library and no longer depends on distutils in the standard library. When importing ``setuptools`` or ``setuptools.distutils_patch``, Setuptools will expose its bundled version as a top-level ``distutils`` package (and unload any previously-imported top-level distutils package), retaining the expectation that ``distutils``' objects are actually Setuptools objects.
To avoid getting any legacy behavior from the standard library, projects are advised to always "import setuptools" prior to importing anything from distutils. This behavior happens by default when using ``pip install`` or ``pep517.build``. Workflows that rely on ``setup.py (anything)`` will need to first ensure setuptools is imported. One way to achieve this behavior without modifying code is to invoke Python thus: ``python -c "import setuptools; exec(open('setup.py').read())" (anything)``.
v47.3.2
=======
Misc
----
* #2071: Replaced references to the deprecated imp package with references to importlib
v47.3.1
=======
Misc
----
* #1973: Removed ``pkg_resources.py31compat.makedirs`` in favor of the stdlib. Use ``os.makedirs()`` instead.
* #2198: Restore ``__requires__`` directive in easy-install wrapper scripts.
v47.3.0
=======
Changes
-------
* #2197: Console script wrapper for editable installs now has a unified template and honors importlib_metadata if present for faster script execution on older Pythons.
Misc
----
* #2195: Fix broken entry points generated by easy-install (pip editable installs).
v47.2.0
=======
Changes
-------
* #2194: Editable-installed entry points now load significantly faster on Python versions 3.8+.
* #1471: Incidentally fixed by #2194 on Python 3.8 or when importlib_metadata is present.
v47.1.1
=======
Documentation changes
---------------------
* #2156: Update mailing list pointer in developer docs
Incorporate changes from v44.1.1:
---------------------------------
* #2158: Avoid loading working set during ``Distribution.finalize_options`` prior to invoking ``_install_setup_requires``, broken since v42.0.0.
v44.1.1
=======
Misc
----
* #2158: Avoid loading working set during ``Distribution.finalize_options`` prior to invoking ``_install_setup_requires``, broken since v42.0.0.
v47.1.0
=======
Changes
-------
* #2070: In wheel-to-egg conversion, use simple pkg_resources-style namespace declaration for packages that declare namespace_packages.
v47.0.0
=======
Breaking Changes
----------------
* #2094: Setuptools now actively crashes under Python 2. Python 3.5 or later is required. Users of Python 2 should use ``setuptools<45``.
Changes
-------
* #1700: Document all supported keywords by migrating the ones from distutils.
v46.4.0
=======
Changes
-------
* #1753: ``attr:`` now extracts variables through rudimentary examination of the AST,
thereby supporting modules with third-party imports. If examining the AST
fails to find the variable, ``attr:`` falls back to the old behavior of
importing the module. Works on Python 3 only.
v46.3.1
=======
No significant changes.
v46.3.0
=======
Changes
-------
* #2089: Package index functionality no longer attempts to remove an md5 fragment from the index URL. This functionality, added for distribute #163 is no longer relevant.
Misc
----
* #2041: Preserve file modes during pkg files copying, but clear read only flag for target afterwards.
* #2105: Filter ``2to3`` deprecation warnings from ``TestDevelop.test_2to3_user_mode``.
v46.2.0
=======
Changes
-------
* #2040: Deprecated the ``bdist_wininst`` command. Binary packages should be built as wheels instead.
* #2062: Change 'Mac OS X' to 'macOS' in code.
* #2075: Stop recognizing files ending with ``.dist-info`` as distribution metadata.
* #2086: Deprecate 'use_2to3' functionality. Packagers are encouraged to use single-source solutions or build tool chains to manage conversions outside of setuptools.
Documentation changes
---------------------
* #1698: Added documentation for ``build_meta`` (a bare minimum, not completed).
Misc
----
* #2082: Filter ``lib2to3`` ``PendingDeprecationWarning`` and ``DeprecationWarning`` in tests,
because ``lib2to3`` is `deprecated in Python 3.9 `_.
v46.1.3
=======
No significant changes.
v46.1.2
=======
Misc
----
* #1458: Added template for reporting Python 2 incompatibilities.
v46.1.1
=======
No significant changes.
v46.1.0
=======
Changes
-------
* #308: Allow version number normalization to be bypassed by wrapping in a 'setuptools.sic()' call.
* #1424: Prevent keeping files mode for package_data build. It may break a build if user's package data has read only flag.
* #1431: In ``easy_install.check_site_dir``, ensure the installation directory exists.
* #1563: In ``pkg_resources`` prefer ``find_spec`` (PEP 451) to ``find_module``.
Incorporate changes from v44.1.0:
---------------------------------
* #1704: Set sys.argv[0] in setup script run by build_meta.__legacy__
* #1959: Fix for Python 4: replace unsafe six.PY3 with six.PY2
* #1994: Fixed a bug in the "setuptools.finalize_distribution_options" hook that lead to ignoring the order attribute of entry points managed by this hook.
v44.1.0
=======
Changes
-------
* #1704: Set sys.argv[0] in setup script run by build_meta.__legacy__
* #1959: Fix for Python 4: replace unsafe six.PY3 with six.PY2
* #1994: Fixed a bug in the "setuptools.finalize_distribution_options" hook that lead to ignoring the order attribute of entry points managed by this hook.
v46.0.0
=======
Breaking Changes
----------------
* #65: Once again as in 3.0, removed the Features feature.
Changes
-------
* #1890: Fix vendored dependencies so importing ``setuptools.extern.some_module`` gives the same object as ``setuptools._vendor.some_module``. This makes Metadata picklable again.
* #1899: Test suite now fails on warnings.
Documentation changes
---------------------
* #2011: Fix broken link to distutils docs on package_data
Misc
----
* #1991: Include pkg_resources test data in sdist, so tests can be executed from it.
v45.3.0
=======
Changes
-------
* #1557: Deprecated eggsecutable scripts and updated docs.
* #1904: Update msvc.py to use CPython 3.8.0 mechanism to find msvc 14+
v45.2.0
=======
Changes
-------
* #1905: Fixed defect in _imp, introduced in 41.6.0 when the 'tests' directory is not present.
* #1941: Improve editable installs with PEP 518 build isolation:
* The ``--user`` option is now always available. A warning is issued if the user site directory is not available.
* The error shown when the install directory is not in ``PYTHONPATH`` has been turned into a warning.
* #1981: Setuptools now declares its ``tests`` and ``docs`` dependencies in metadata (extras).
* #1985: Add support for installing scripts in environments where bdist_wininst is missing (i.e. Python 3.9).
Misc
----
* #1968: Add flake8-2020 to check for misuse of sys.version or sys.version_info.
v45.1.0
=======
Changes
-------
* #1458: Add minimum sunset date and preamble to Python 2 warning.
* #1704: Set sys.argv[0] in setup script run by build_meta.__legacy__
* #1974: Add Python 3 Only Trove Classifier and remove universal wheel declaration for more complete transition from Python 2.
v45.0.0
=======
Breaking Changes
----------------
* #1458: Drop support for Python 2. Setuptools now requires Python 3.5 or later. Install setuptools using pip >=9 or pin to Setuptools <45 to maintain 2.7 support.
Changes
-------
* #1959: Fix for Python 4: replace unsafe six.PY3 with six.PY2
v44.0.0
=======
Breaking Changes
----------------
* #1908: Drop support for Python 3.4.
v43.0.0
=======
Breaking Changes
----------------
* #1634: Include ``pyproject.toml`` in source distribution by default. Projects relying on the previous behavior where ``pyproject.toml`` was excluded by default should stop relying on that behavior or add ``exclude pyproject.toml`` to their MANIFEST.in file.
Changes
-------
* #1927: Setuptools once again declares 'setuptools' in the ``build-system.requires`` and adds PEP 517 build support by declaring itself as the ``build-backend``. It additionally specifies ``build-system.backend-path`` to rely on itself for those builders that support it.
v42.0.2
=======
Changes
-------
* #1921: Fix support for easy_install's ``find-links`` option in ``setup.cfg``.
* #1922: Build dependencies (setup_requires and tests_require) now install transitive dependencies indicated by extras.
v42.0.1
=======
Changes
-------
* #1918: Fix regression in handling wheels compatibility tags.
v42.0.0
=======
Breaking Changes
----------------
* #1830, #1909: Mark the easy_install script and setuptools command as deprecated, and use `pip `_ when available to fetch/build wheels for missing ``setup_requires``/``tests_require`` requirements, with the following differences in behavior:
* support for ``python_requires``
* better support for wheels (proper handling of priority with respect to PEP 425 tags)
* PEP 517/518 support
* eggs are not supported
* no support for the ``allow_hosts`` easy_install option (``index_url``/``find_links`` are still honored)
* pip environment variables are honored (and take precedence over easy_install options)
* #1898: Removed the "upload" and "register" commands in favor of :pypi:`twine`.
Changes
-------
* #1767: Add support for the ``license_files`` option in ``setup.cfg`` to automatically
include multiple license files in a source distribution.
* #1829: Update handling of wheels compatibility tags:
* add support for manylinux2010
* fix use of removed 'm' ABI flag in Python 3.8 on Windows
* #1861: Fix empty namespace package installation from wheel.
* #1877: Setuptools now exposes a new entry point hook "setuptools.finalize_distribution_options", enabling plugins like :pypi:`setuptools_scm` to configure options on the distribution at finalization time.
v41.6.0
=======
Changes
-------
* #479: Replace usage of deprecated ``imp`` module with local re-implementation in ``setuptools._imp``.
v41.5.1
=======
Changes
-------
* #1891: Fix code for detecting Visual Studio's version on Windows under Python 2.
v41.5.0
=======
Changes
-------
* #1811: Improve Visual C++ 14.X support, mainly for Visual Studio 2017 and 2019.
* #1814: Fix ``pkg_resources.Requirement`` hash/equality implementation: take PEP 508 direct URL into account.
* #1824: Fix tests when running under ``python3.10``.
* #1878: Formally deprecated the ``test`` command, with the recommendation that users migrate to ``tox``.
Documentation changes
---------------------
* #1860: Update documentation to mention the egg format is not supported by pip and dependency links support was dropped starting with pip 19.0.
* #1862: Drop ez_setup documentation: deprecated for some time (last updated in 2016), and still relying on easy_install (deprecated too).
* #1868: Drop most documentation references to (deprecated) EasyInstall.
* #1884: Added a trove classifier to document support for Python 3.8.
Misc
----
* #1886: Added Python 3.8 release to the Travis test matrix.
v41.4.0
=======
Changes
-------
* #1847: In declarative config, now traps errors when invalid ``python_requires`` values are supplied.
v41.3.0
=======
Changes
-------
* #1690: When storing extras, rely on OrderedSet to retain order of extras as indicated by the packager, which will also be deterministic on Python 2.7 (with PYTHONHASHSEED unset) and Python 3.6+.
Misc
----
* #1858: Fixed failing integration test triggered by 'long_description_content_type' in packaging.
v41.2.0
=======
Changes
-------
* #479: Remove some usage of the deprecated ``imp`` module.
Misc
----
* #1565: Changed html_sidebars from string to list of string as per
https://www.sphinx-doc.org/en/master/changes.html#id58
v41.1.0
=======
Misc
----
* #1697: Moved most of the constants from setup.py to setup.cfg
* #1749: Fixed issue with the PEP 517 backend where building a source distribution would fail if any tarball existed in the destination directory.
* #1750: Fixed an issue with PEP 517 backend where wheel builds would fail if the destination directory did not already exist.
* #1756: Force metadata-version >= 1.2. when project urls are present.
* #1769: Improve ``package_data`` check: ensure the dictionary values are lists/tuples of strings.
* #1788: Changed compatibility fallback logic for ``html.unescape`` to avoid accessing ``HTMLParser.unescape`` when not necessary. ``HTMLParser.unescape`` is deprecated and will be removed in Python 3.9.
* #1790: Added the file path to the error message when a ``UnicodeDecodeError`` occurs while reading a metadata file.
Documentation changes
---------------------
* #1776: Use license classifiers rather than the license field.
v41.0.1
=======
Changes
-------
* #1671: Fixed issue with the PEP 517 backend that prevented building a wheel when the ``dist/`` directory contained existing ``.whl`` files.
* #1709: In test.paths_on_python_path, avoid adding unnecessary duplicates to the PYTHONPATH.
* #1741: In package_index, now honor "current directory" during a checkout of git and hg repositories under Windows
v41.0.0
=======
Breaking Changes
----------------
* #1735: When parsing setup.cfg files, setuptools now requires the files to be encoded as UTF-8. Any other encoding will lead to a UnicodeDecodeError. This change removes support for specifying an encoding using a 'coding: ' directive in the header of the file, a feature that was introduces in 40.7. Given the recent release of the aforementioned feature, it is assumed that few if any projects are utilizing the feature to specify an encoding other than UTF-8.
v40.9.0
=======
Changes
-------
* #1675: Added support for ``setup.cfg``-only projects when using the ``setuptools.build_meta`` backend. Projects that have enabled PEP 517 no longer need to have a ``setup.py`` and can use the purely declarative ``setup.cfg`` configuration file instead.
* #1720: Added support for ``pkg_resources.parse_requirements``-style requirements in ``setup_requires`` when ``setup.py`` is invoked from the ``setuptools.build_meta`` build backend.
* #1664: Added the path to the ``PKG-INFO`` or ``METADATA`` file in the exception
text when the ``Version:`` header can't be found.
Documentation changes
---------------------
* #1705: Removed some placeholder documentation sections referring to deprecated features.
v40.8.0
=======
Changes
-------
* #1652: Added the ``build_meta:__legacy__`` backend, a "compatibility mode" PEP 517 backend that can be used as the default when ``build-backend`` is left unspecified in ``pyproject.toml``.
* #1635: Resource paths are passed to ``pkg_resources.resource_string`` and similar no longer accept paths that traverse parents, that begin with a leading ``/``. Violations of this expectation raise DeprecationWarnings and will become errors. Additionally, any paths that are absolute on Windows are strictly disallowed and will raise ValueErrors.
* #1536: ``setuptools`` will now automatically include licenses if ``setup.cfg`` contains a ``license_file`` attribute, unless this file is manually excluded inside ``MANIFEST.in``.
v40.7.3
=======
Changes
-------
* #1670: In package_index, revert to using a copy of splituser from Python 3.8. Attempts to use ``urllib.parse.urlparse`` led to problems as reported in #1663 and #1668. This change serves as an alternative to #1499 and fixes #1668.
v40.7.2
=======
Changes
-------
* #1666: Restore port in URL handling in package_index.
v40.7.1
=======
Changes
-------
* #1660: On Python 2, when reading config files, downcast options from text to bytes to satisfy distutils expectations.
v40.7.0
=======
Breaking Changes
----------------
* #1551: File inputs for the ``license`` field in ``setup.cfg`` files now explicitly raise an error.
Changes
-------
* #1180: Add support for non-ASCII in setup.cfg (#1062). Add support for native strings on some parameters (#1136).
* #1499: ``setuptools.package_index`` no longer relies on the deprecated ``urllib.parse.splituser`` per Python #27485.
* #1544: Added tests for PackageIndex.download (for git URLs).
* #1625: In PEP 517 build_meta builder, ensure that sdists are built as gztar per the spec.
v40.6.3
=======
Changes
-------
* #1594: PEP 517 backend no longer declares setuptools as a dependency as it can be assumed.
v40.6.2
=======
Changes
-------
* #1592: Fix invalid dependency on external six module (instead of vendored version).
v40.6.1
=======
Changes
-------
* #1590: Fixed regression where packages without ``author`` or ``author_email`` fields generated malformed package metadata.
v40.6.0
=======
Deprecations
------------
* #1541: Officially deprecated the ``requires`` parameter in ``setup()``.
Changes
-------
* #1519: In ``pkg_resources.normalize_path``, additional path normalization is now performed to ensure path values to a directory is always the same, preventing false positives when checking scripts have a consistent prefix to set up on Windows.
* #1545: Changed the warning class of all deprecation warnings; deprecation warning classes are no longer derived from ``DeprecationWarning`` and are thus visible by default.
* #1554: ``build_meta.build_sdist`` now includes ``setup.py`` in source distributions by default.
* #1576: Started monkey-patching ``get_metadata_version`` and ``read_pkg_file`` onto ``distutils.DistributionMetadata`` to retain the correct version on the ``PKG-INFO`` file in the (deprecated) ``upload`` command.
Documentation changes
---------------------
* #1395: Changed Pyrex references to Cython in the documentation.
* #1456: Documented that the ``rpmbuild`` packages is required for the ``bdist_rpm`` command.
* #1537: Documented how to use ``setup.cfg`` for ``src/ layouts``
* #1539: Added minimum version column in ``setup.cfg`` metadata table.
* #1552: Fixed a minor typo in the python 2/3 compatibility documentation.
* #1553: Updated installation instructions to point to ``pip install`` instead of ``ez_setup.py``.
* #1560: Updated ``setuptools`` distribution documentation to remove some outdated information.
* #1564: Documented ``setup.cfg`` minimum version for version and project_urls.
Misc
----
* #1533: Restricted the ``recursive-include setuptools/_vendor`` to contain only .py and .txt files.
* #1572: Added the ``concurrent.futures`` backport ``futures`` to the Python 2.7 test suite requirements.
v40.5.0
=======
Changes
-------
* #1335: In ``pkg_resources.normalize_path``, fix issue on Cygwin when cwd contains symlinks.
* #1502: Deprecated support for downloads from Subversion in package_index/easy_install.
* #1517: Dropped use of six.u in favor of ``u""`` literals.
* #1520: Added support for ``data_files`` in ``setup.cfg``.
Documentation changes
---------------------
* #1525: Fixed rendering of the deprecation warning in easy_install doc.
v40.4.3
=======
Changes
-------
* #1480: Bump vendored pyparsing in pkg_resources to 2.2.1.
v40.4.2
=======
Misc
----
* #1497: Updated gitignore in repo.
v40.4.1
=======
Changes
-------
* #1480: Bump vendored pyparsing to 2.2.1.
v40.4.0
=======
Changes
-------
* #1481: Join the sdist ``--dist-dir`` and the ``build_meta`` sdist directory argument to point to the same target (meaning the build frontend no longer needs to clean manually the dist dir to avoid multiple sdist presence, and setuptools no longer needs to handle conflicts between the two).
v40.3.0
=======
Changes
-------
* #1402: Fixed a bug with namespace packages under Python 3.6 when one package in
current directory hides another which is installed.
* #1427: Set timestamp of ``.egg-info`` directory whenever ``egg_info`` command is run.
* #1474: ``build_meta.get_requires_for_build_sdist`` now does not include the ``wheel`` package anymore.
* #1486: Suppress warnings in pkg_resources.handle_ns.
Misc
----
* #1479: Remove internal use of six.binary_type.
v40.2.0
=======
Changes
-------
* #1466: Fix handling of Unicode arguments in PEP 517 backend
v40.1.1
========
Changes
-------
* #1465: Fix regression with ``egg_info`` command when tagging is used.
v40.1.0
=======
Changes
-------
* #1410: Deprecated ``upload`` and ``register`` commands.
* #1312: Introduced find_namespace_packages() to find PEP 420 namespace packages.
* #1420: Added find_namespace: directive to config parser.
* #1418: Solved race in when creating egg cache directories.
* #1450: Upgraded vendored PyParsing from 2.1.10 to 2.2.0.
* #1451: Upgraded vendored appdirs from 1.4.0 to 1.4.3.
* #1388: Fixed "Microsoft Visual C++ Build Tools" link in exception when Visual C++ not found.
* #1389: Added support for scripts which have unicode content.
* #1416: Moved several Python version checks over to using ``six.PY2`` and ``six.PY3``.
Misc
----
* #1441: Removed spurious executable permissions from files that don't need them.
v40.0.0
=======
Breaking Changes
----------------
* #1342: Drop support for Python 3.3.
Changes
-------
* #1366: In package_index, fixed handling of encoded entities in URLs.
* #1383: In pkg_resources VendorImporter, avoid removing packages imported from the root.
Documentation changes
---------------------
* #1379: Minor doc fixes after actually using the new release process.
* #1385: Removed section on non-package data files.
* #1403: Fix developer's guide.
Misc
----
* #1404: Fix PEP 518 configuration: set build requirements in ``pyproject.toml`` to ``["wheel"]``.
v39.2.0
=======
Changes
-------
* #1359: Support using "file:" to load a PEP 440-compliant package version from
a text file.
* #1360: Fixed issue with a mismatch between the name of the package and the
name of the .dist-info file in wheel files
* #1364: Add ``__dir__()`` implementation to ``pkg_resources.Distribution()`` that
includes the attributes in the ``_provider`` instance variable.
* #1365: Take the package_dir option into account when loading the version from
a module attribute.
Documentation changes
---------------------
* #1353: Added coverage badge to README.
* #1356: Made small fixes to the developer guide documentation.
* #1357: Fixed warnings in documentation builds and started enforcing that the
docs build without warnings in tox.
* #1376: Updated release process docs.
Misc
----
* #1343: The ``setuptools`` specific ``long_description_content_type``,
``project_urls`` and ``provides_extras`` fields are now set consistently
after any ``distutils`` ``setup_keywords`` calls, allowing them to override
values.
* #1352: Added ``tox`` environment for documentation builds.
* #1354: Added ``towncrier`` for changelog management.
* #1355: Add PR template.
* #1368: Fixed tests which failed without network connectivity.
* #1369: Added unit tests for PEP 425 compatibility tags support.
* #1372: Stop testing Python 3.3 in Travis CI, now that the latest version of
``wheel`` no longer installs on it.
v39.1.0
=======
* #1340: Update all PyPI URLs to reflect the switch to the
new Warehouse codebase.
* #1337: In ``pkg_resources``, now support loading resources
for modules loaded by the ``SourcelessFileLoader``.
* #1332: Silence spurious wheel related warnings on Windows.
v39.0.1
=======
* #1297: Restore Unicode handling for Maintainer fields in
metadata.
v39.0.0
=======
* #1296: Setuptools now vendors its own direct dependencies, no
longer relying on the dependencies as vendored by pkg_resources.
* #296: Removed long-deprecated support for iteration on
Version objects as returned by ``pkg_resources.parse_version``.
Removed the ``SetuptoolsVersion`` and
``SetuptoolsLegacyVersion`` names as well. They should not
have been used, but if they were, replace with
``Version`` and ``LegacyVersion`` from ``packaging.version``.
v38.7.0
=======
* #1288: Add support for maintainer in PKG-INFO.
v38.6.1
=======
* #1292: Avoid generating ``Provides-Extra`` in metadata when
no extra is present (but environment markers are).
v38.6.0
=======
* #1286: Add support for Metadata 2.1 (PEP 566).
v38.5.2
=======
* #1285: Fixed RuntimeError in pkg_resources.parse_requirements
on Python 3.7 (stemming from PEP 479).
v38.5.1
=======
* #1271: Revert to Cython legacy ``build_ext`` behavior for
compatibility.
v38.5.0
=======
* #1229: Expand imports in ``build_ext`` to refine detection of
Cython availability.
* #1270: When Cython is available, ``build_ext`` now uses the
new_build_ext.
v38.4.1
=======
* #1257: In bdist_egg.scan_module, fix ValueError on Python 3.7.
v38.4.0
=======
* #1231: Removed warning when PYTHONDONTWRITEBYTECODE is enabled.
v38.3.0
=======
* #1210: Add support for PEP 345 Project-URL metadata.
* #1207: Add support for ``long_description_type`` to setup.cfg
declarative config as intended and documented.
v38.2.5
=======
* #1232: Fix trailing slash handling in ``pkg_resources.ZipProvider``.
v38.2.4
=======
* #1220: Fix ``data_files`` handling when installing from wheel.
v38.2.3
=======
* fix Travis' Python 3.3 job.
v38.2.2
=======
* #1214: fix handling of namespace packages when installing
from a wheel.
v38.2.1
=======
* #1212: fix encoding handling of metadata when installing
from a wheel.
v38.2.0
=======
* #1200: easy_install now support installing from wheels:
they will be installed as standalone unzipped eggs.
v38.1.0
=======
* #1208: Improve error message when failing to locate scripts
in egg-info metadata.
v38.0.0
=======
* #458: In order to support deterministic builds, Setuptools no
longer allows packages to declare ``install_requires`` as
unordered sequences (sets or dicts).
v37.0.0
=======
* #878: Drop support for Python 2.6. Python 2.6 users should
rely on 'setuptools < 37dev'.
v36.8.0
=======
* #1190: In SSL support for package index operations, use SNI
where available.
v36.7.3
=======
* #1175: Bug fixes to ``build_meta`` module.
v36.7.2
=======
* #701: Fixed duplicate test discovery on Python 3.
v36.7.1
=======
* #1193: Avoid test failures in bdist_egg when
PYTHONDONTWRITEBYTECODE is set.
v36.7.0
=======
* #1054: Support ``setup_requires`` in ``setup.cfg`` files.
v36.6.1
=======
* #1132: Removed redundant and costly serialization/parsing step
in ``EntryPoint.__init__``.
* #844: ``bdist_egg --exclude-source-files`` now tested and works
on Python 3.
v36.6.0
=======
* #1143: Added ``setuptools.build_meta`` module, an implementation
of PEP-517 for Setuptools-defined packages.
* #1143: Added ``dist_info`` command for producing dist_info
metadata.
v36.5.0
=======
* #170: When working with Mercurial checkouts, use Windows-friendly
syntax for suppressing output.
* Inspired by #1134, performed substantial refactoring of
``pkg_resources.find_on_path`` to facilitate an optimization
for paths with many non-version entries.
v36.4.0
=======
* #1075: Add new ``Description-Content-Type`` metadata field. `See here for
documentation on how to use this field.
`_
* #1068: Sort files and directories when building eggs for
deterministic order.
* #196: Remove caching of easy_install command in fetch_build_egg.
Fixes issue where ``pytest-runner-N.N`` would satisfy the installation
of ``pytest``.
* #1129: Fix working set dependencies handling when replacing conflicting
distributions (e.g. when using ``setup_requires`` with a conflicting
transitive dependency, fix #1124).
* #1133: Improved handling of README files extensions and added
Markdown to the list of searched READMES.
* #1135: Improve performance of pkg_resources import by not invoking
``access`` or ``stat`` and using ``os.listdir`` instead.
v36.3.0
=======
* #1131: Make possible using several files within ``file:`` directive
in metadata.long_description in ``setup.cfg``.
v36.2.7
=======
* fix #1105: Fix handling of requirements with environment
markers when declared in ``setup.cfg`` (same treatment as
for #1081).
v36.2.6
=======
* #462: Don't assume a directory is an egg by the ``.egg``
extension alone.
v36.2.5
=======
* #1093: Fix test command handler with extras_require.
* #1112, #1091, #1115: Now using Trusty containers in
Travis for CI and CD.
v36.2.4
=======
* #1092: ``pkg_resources`` now uses ``inspect.getmro`` to
resolve classes in method resolution order.
v36.2.3
=======
* #1102: Restore behavior for empty extras.
v36.2.2
=======
* #1099: Revert commit a3ec721, restoring intended purpose of
extras as part of a requirement declaration.
v36.2.1
=======
* fix #1086
* fix #1087
* support extras specifiers in install_requires requirements
v36.2.0
=======
* #1081: Environment markers indicated in ``install_requires``
are now processed and treated as nameless ``extras_require``
with markers, allowing their metadata in requires.txt to be
correctly generated.
* #1053: Tagged commits are now released using Travis-CI
build stages, meaning releases depend on passing tests on
all supported Python versions (Linux) and not just the latest
Python version.
v36.1.1
=======
* #1083: Correct ``py31compat.makedirs`` to correctly honor
``exist_ok`` parameter.
* #1083: Also use makedirs compatibility throughout setuptools.
v36.1.0
=======
* #1083: Avoid race condition on directory creation in
``pkg_resources.ensure_directory``.
* Removed deprecation of and restored support for
``upload_docs`` command for sites other than PyPI.
Only warehouse is dropping support, but services like
`devpi `_ continue to
support docs built by setuptools' plugins. See
`this comment `_
for more context on the motivation for this change.
v36.0.1
=======
* #1042: Fix import in py27compat module that still
referenced six directly, rather than through the externs
module (vendored packages hook).
v36.0.0
=======
* #980 and others: Once again, Setuptools vendors all
of its dependencies. It seems to be the case that in
the Python ecosystem, all build tools must run without
any dependencies (build, runtime, or otherwise). At
such a point that a mechanism exists that allows
build tools to have dependencies, Setuptools will adopt
it.
v35.0.2
=======
* #1015: Fix test failures on Python 3.7.
* #1024: Add workaround for Jython #2581 in monkey module.
v35.0.1
=======
* #992: Revert change introduced in v34.4.1, now
considered invalid.
* #1016: Revert change introduced in v35.0.0 per #1014,
referencing #436. The approach had unintended
consequences, causing sdist installs to be missing
files.
v35.0.0
=======
* #436: In egg_info.manifest_maker, no longer read
the file list from the manifest file, and instead
re-build it on each build. In this way, files removed
from the specification will not linger in the manifest.
As a result, any files manually added to the manifest
will be removed on subsequent egg_info invocations.
No projects should be manually adding files to the
manifest and should instead use MANIFEST.in or SCM
file finders to force inclusion of files in the manifest.
v34.4.1
=======
* #1008: In MSVC support, use always the last version available for Windows SDK and UCRT SDK.
* #1008: In MSVC support, fix "vcruntime140.dll" returned path with Visual Studio 2017.
* #992: In msvc.msvc9_query_vcvarsall, ensure the
returned dicts have str values and not Unicode for
compatibility with os.environ.
v34.4.0
=======
* #995: In MSVC support, add support for "Microsoft Visual Studio 2017" and "Microsoft Visual Studio Build Tools 2017".
* #999 via #1007: Extend support for declarative package
config in a setup.cfg file to include the options
``python_requires`` and ``py_modules``.
v34.3.3
=======
* #967 (and #997): Explicitly import submodules of
packaging to account for environments where the imports
of those submodules is not implied by other behavior.
v34.3.2
=======
* #993: Fix documentation upload by correcting
rendering of content-type in _build_multipart
on Python 3.
v34.3.1
=======
* #988: Trap ``os.unlink`` same as ``os.remove`` in
``auto_chmod`` error handler.
* #983: Fixes to invalid escape sequence deprecations on
Python 3.6.
v34.3.0
=======
* #941: In the upload command, if the username is blank,
default to ``getpass.getuser()``.
* #971: Correct distutils findall monkeypatch to match
appropriate versions (namely Python 3.4.6).
v34.2.0
=======
* #966: Add support for reading dist-info metadata and
thus locating Distributions from zip files.
* #968: Allow '+' and '!' in egg fragments
so that it can take package names that contain
PEP 440 conforming version specifiers.
v34.1.1
=======
* #953: More aggressively employ the compatibility issue
originally added in #706.
v34.1.0
=======
* #930: ``build_info`` now accepts two new parameters
to optimize and customize the building of C libraries.
v34.0.3
=======
* #947: Loosen restriction on the version of six required,
restoring compatibility with environments relying on
six 1.6.0 and later.
v34.0.2
=======
* #882: Ensure extras are honored when building the
working set.
* #913: Fix issue in develop if package directory has
a trailing slash.
v34.0.1
=======
* #935: Fix glob syntax in graft.
v34.0.0
=======
* #581: Instead of vendoring the growing list of
dependencies that Setuptools requires to function,
Setuptools now requires these dependencies just like
any other project. Unlike other projects, however,
Setuptools cannot rely on ``setup_requires`` to
demand the dependencies it needs to install because
its own machinery would be necessary to pull those
dependencies if not present (a bootstrapping problem).
As a result, Setuptools no longer supports self upgrade or
installation in the general case. Instead, users are
directed to use pip to install and upgrade using the
``wheel`` distributions of setuptools.
Users are welcome to contrive other means to install
or upgrade Setuptools using other means, such as
pre-installing the Setuptools dependencies with pip
or a bespoke bootstrap tool, but such usage is not
recommended and is not supported.
As discovered in #940, not all versions of pip will
successfully install Setuptools from its pre-built
wheel. If you encounter issues with "No module named
six" or "No module named packaging", especially
following a line "Running setup.py egg_info for package
setuptools", then your pip is not new enough.
There's an additional issue in pip where setuptools
is upgraded concurrently with other source packages,
described in pip #4253. The proposed workaround is to
always upgrade Setuptools first prior to upgrading
other packages that would upgrade Setuptools.
v33.1.1
=======
* #921: Correct issue where certifi fallback not being
reached on Windows.
v33.1.0
=======
Installation via pip, as indicated in the `Python Packaging
User's Guide `_,
is the officially-supported mechanism for installing
Setuptools, and this recommendation is now explicit in the
much more concise README.
Other edits and tweaks were made to the documentation. The
codebase is unchanged.
v33.0.0
=======
* #619: Removed support for the ``tag_svn_revision``
distribution option. If Subversion tagging support is
still desired, consider adding the functionality to
setuptools_svn in setuptools_svn #2.
v32.3.1
=======
* #866: Use ``dis.Bytecode`` on Python 3.4 and later in
``setuptools.depends``.
v32.3.0
=======
* #889: Backport proposed fix for disabling interpolation in
distutils.Distribution.parse_config_files.
v32.2.0
=======
* #884: Restore support for running the tests under
`pytest-runner `_
by ensuring that PYTHONPATH is honored in tests invoking
a subprocess.
v32.1.3
=======
* #706: Add rmtree compatibility shim for environments where
rmtree fails when passed a unicode string.
v32.1.2
=======
* #893: Only release sdist in zip format as warehouse now
disallows releasing two different formats.
v32.1.1
=======
* #704: More selectively ensure that 'rmtree' is not invoked with
a byte string, enabling it to remove files that are non-ascii,
even on Python 2.
* #712: In 'sandbox.run_setup', ensure that ``__file__`` is
always a ``str``, modeling the behavior observed by the
interpreter when invoking scripts and modules.
v32.1.0
=======
* #891: In 'test' command on test failure, raise DistutilsError,
suppression invocation of subsequent commands.
v32.0.0
=======
* #890: Revert #849. ``global-exclude .foo`` will not match all
``*.foo`` files any more. Package authors must add an explicit
wildcard, such as ``global-exclude *.foo``, to match all
``.foo`` files. See #886, #849.
v31.0.1
=======
* #885: Fix regression where 'pkg_resources._rebuild_mod_path'
would fail when a namespace package's '__path__' was not
a list with a sort attribute.
v31.0.0
=======
* #250: Install '-nspkg.pth' files for packages installed
with 'setup.py develop'. These .pth files allow
namespace packages installed by pip or develop to
co-mingle. This change required the removal of the
change for #805 and pip #1924, introduced in 28.3.0 and implicated
in #870, but means that namespace packages not in a
site packages directory will no longer work on Python
earlier than 3.5, whereas before they would work on
Python not earlier than 3.3.
v30.4.0
=======
* #879: For declarative config:
- read_configuration() now accepts ignore_option_errors argument. This allows scraping tools to read metadata without a need to download entire packages. E.g. we can gather some stats right from GitHub repos just by downloading setup.cfg.
- packages find: directive now supports fine tuning from a subsection. The same arguments as for find() are accepted.
v30.3.0
=======
* #394 via #862: Added support for `declarative package
config in a setup.cfg file
`_.
v30.2.1
=======
* #850: In test command, invoke unittest.main with
indication not to exit the process.
v30.2.0
=======
* #854: Bump to vendored Packaging 16.8.
v30.1.0
=======
* #846: Also trap 'socket.error' when opening URLs in
package_index.
* #849: Manifest processing now matches the filename
pattern anywhere in the filename and not just at the
start. Restores behavior found prior to 28.5.0.
v30.0.0
=======
* #864: Drop support for Python 3.2. Systems requiring
Python 3.2 support must use 'setuptools < 30'.
* #825: Suppress warnings for single files.
* #830 via #843: Once again restored inclusion of data
files to sdists, but now trap TypeError caused by
techniques employed rjsmin and similar.
v29.0.1
=======
* #861: Re-release of v29.0.1 with the executable script
launchers bundled. Now, launchers are included by default
and users that want to disable this behavior must set the
environment variable
'SETUPTOOLS_INSTALL_WINDOWS_SPECIFIC_FILES' to
a false value like "false" or "0".
v29.0.0
=======
* #841: Drop special exception for packages invoking
win32com during the build/install process. See
Distribute #118 for history.
v28.8.0
=======
* #629: Per the discussion, refine the sorting to use version
value order for more accurate detection of the latest
available version when scanning for packages. See also
#829.
* #837: Rely on the config var "SO" for Python 3.3.0 only
when determining the ext filename.
v28.7.1
=======
* #827: Update PyPI root for dependency links.
* #833: Backed out changes from #830 as the implementation
seems to have problems in some cases.
v28.7.0
=======
* #832: Moved much of the namespace package handling
functionality into a separate module for re-use in something
like #789.
* #830: ``sdist`` command no longer suppresses the inclusion
of data files, re-aligning with the expectation of distutils
and addressing #274 and #521.
v28.6.1
=======
* #816: Fix manifest file list order in tests.
v28.6.0
=======
* #629: When scanning for packages, ``pkg_resources`` now
ignores empty egg-info directories and gives precedence to
packages whose versions are lexicographically greatest,
a rough approximation for preferring the latest available
version.
v28.5.0
=======
* #810: Tests are now invoked with tox and not setup.py test.
* #249 and #450 via #764: Avoid scanning the whole tree
when building the manifest. Also fixes a long-standing bug
where patterns in ``MANIFEST.in`` had implicit wildcard
matching. This caused ``global-exclude .foo`` to exclude
all ``*.foo`` files, but also ``global-exclude bar.py`` to
exclude ``foo_bar.py``.
v28.4.0
=======
* #732: Now extras with a hyphen are honored per PEP 426.
* #811: Update to pyparsing 2.1.10.
* Updated ``setuptools.command.sdist`` to re-use most of
the functionality directly from ``distutils.command.sdist``
for the ``add_defaults`` method with strategic overrides.
See #750 for rationale.
* #760 via #762: Look for certificate bundle where SUSE
Linux typically presents it. Use ``certifi.where()`` to locate
the bundle.
v28.3.0
=======
* #809: In ``find_packages()``, restore support for excluding
a parent package without excluding a child package.
* #805: Disable ``-nspkg.pth`` behavior on Python 3.3+ where
PEP-420 functionality is adequate. Fixes pip #1924.
v28.1.0
=======
* #803: Bump certifi to 2016.9.26.
v28.0.0
=======
* #733: Do not search excluded directories for packages.
This introduced a backwards incompatible change in ``find_packages()``
so that ``find_packages(exclude=['foo']) == []``, excluding subpackages of ``foo``.
Previously, ``find_packages(exclude=['foo']) == ['foo.bar']``,
even though the parent ``foo`` package was excluded.
* #795: Bump certifi.
* #719: Suppress decoding errors and instead log a warning
when metadata cannot be decoded.
v27.3.1
=======
* #790: In MSVC monkeypatching, explicitly patch each
function by name in the target module instead of inferring
the module from the function's ``__module__``. Improves
compatibility with other packages that might have previously
patched distutils functions (i.e. NumPy).
v27.3.0
=======
* #794: In test command, add installed eggs to PYTHONPATH
when invoking tests so that subprocesses will also have the
dependencies available. Fixes `tox 330
`_.
* #795: Update vendored pyparsing 2.1.9.
v27.2.0
=======
* #520 and #513: Suppress ValueErrors in fixup_namespace_packages
when lookup fails.
* Nicer, more consistent interfaces for msvc monkeypatching.
v27.1.2
=======
* #779 via #781: Fix circular import.
v27.1.1
=======
* #778: Fix MSVC monkeypatching.
v27.1.0
=======
* Introduce the (private) ``monkey`` module to encapsulate
the distutils monkeypatching behavior.
v27.0.0
=======
* Now use Warehouse by default for
``upload``, patching ``distutils.config.PyPIRCCommand`` to
affect default behavior.
Any config in .pypirc should be updated to replace
https://pypi.python.org/pypi/
with
https://upload.pypi.org/legacy/
Similarly, any passwords stored in the keyring should be
updated to use this new value for "system".
The ``upload_docs`` command will continue to use the python.org
site, but the command is now deprecated. Users are urged to use
Read The Docs instead.
* #776: Use EXT_SUFFIX for py_limited_api renaming.
* #774 and #775: Use LegacyVersion from packaging when
detecting numpy versions.
v26.1.1
=======
* Re-release of 26.1.0 with pytest pinned to allow for automated
deployment and thus proper packaging environment variables,
fixing issues with missing executable launchers.
v26.1.0
=======
* #763: ``pkg_resources.get_default_cache`` now defers to the
:pypi:`appdirs` project to
resolve the cache directory. Adds a vendored dependency on
appdirs to pkg_resources.
v26.0.0
=======
* #748: By default, sdists are now produced in gzipped tarfile
format by default on all platforms, adding forward compatibility
for the same behavior in Python 3.6 (See Python #27819).
* #459 via #736: On Windows with script launchers,
sys.argv[0] now reflects
the name of the entry point, consistent with the behavior in
distlib and pip wrappers.
* #752 via #753: When indicating ``py_limited_api`` to Extension,
it must be passed as a keyword argument.
v25.4.0
=======
* Add Extension(py_limited_api=True). When set to a truthy value,
that extension gets a filename appropriate for code using Py_LIMITED_API.
When used correctly this allows a single compiled extension to work on
all future versions of CPython 3.
The py_limited_api argument only controls the filename. To be
compatible with multiple versions of Python 3, the C extension
will also need to set -DPy_LIMITED_API=... and be modified to use
only the functions in the limited API.
v25.3.0
=======
* #739 Fix unquoted libpaths by fixing compatibility between ``numpy.distutils`` and ``distutils._msvccompiler`` for numpy < 1.11.2 (Fix issue #728, error also fixed in Numpy).
* #731: Bump certifi.
* Style updates. See #740, #741, #743, #744, #742, #747.
* #735: include license file.
v25.2.0
=======
* #612 via #730: Add a LICENSE file which needs to be provided by the terms of
the MIT license.
v25.1.6
=======
* #725: revert ``library_dir_option`` patch (Error is related to ``numpy.distutils`` and make errors on non Numpy users).
v25.1.5
=======
* #720
* #723: Improve patch for ``library_dir_option``.
v25.1.4
=======
* #717
* #713
* #707: Fix Python 2 compatibility for MSVC by catching errors properly.
* #715: Fix unquoted libpaths by patching ``library_dir_option``.
v25.1.3
=======
* #714 and #704: Revert fix as it breaks other components
downstream that can't handle unicode. See #709, #710,
and #712.
v25.1.2
=======
* #704: Fix errors when installing a zip sdist that contained
files named with non-ascii characters on Windows would
crash the install when it attempted to clean up the build.
* #646: MSVC compatibility - catch errors properly in
RegistryInfo.lookup.
* #702: Prevent UnboundLocalError when initial working_set
is empty.
v25.1.1
=======
* #686: Fix issue in sys.path ordering by pkg_resources when
rewrite technique is "raw".
* #699: Fix typo in msvc support.
v25.1.0
=======
* #609: Setuptools will now try to download a distribution from
the next possible download location if the first download fails.
This means you can now specify multiple links as ``dependency_links``
and all links will be tried until a working download link is encountered.
v25.0.2
=======
* #688: Fix AttributeError in setup.py when invoked not from
the current directory.
v25.0.1
=======
* Cleanup of setup.py script.
* Fixed documentation builders by allowing setup.py
to be imported without having bootstrapped the
metadata.
* More style cleanup. See #677, #678, #679, #681, #685.
v25.0.0
=======
* #674: Default ``sys.path`` manipulation by easy-install.pth
is now "raw", meaning that when writing easy-install.pth
during any install operation, the ``sys.path`` will not be
rewritten and will no longer give preference to easy_installed
packages.
To retain the old behavior when using any easy_install
operation (including ``setup.py install`` when setuptools is
present), set the environment variable:
SETUPTOOLS_SYS_PATH_TECHNIQUE=rewrite
This project hopes that that few if any environments find it
necessary to retain the old behavior, and intends to drop
support for it altogether in a future release. Please report
any relevant concerns in the ticket for this change.
v24.3.1
=======
* #398: Fix shebang handling on Windows in script
headers where spaces in ``sys.executable`` would
produce an improperly-formatted shebang header,
introduced in 12.0 with the fix for #188.
* #663, #670: More style updates.
v24.3.0
=======
* #516: Disable ``os.link`` to avoid hard linking
in ``sdist.make_distribution``, avoiding errors on
systems that support hard links but not on the
file system in which the build is occurring.
v24.2.1
=======
* #667: Update Metadata-Version to 1.2 when
``python_requires`` is supplied.
v24.2.0
=======
* #631: Add support for ``python_requires`` keyword.
v24.1.1
=======
* More style updates. See #660, #661, #641.
v24.1.0
=======
* #659: ``setup.py`` now will fail fast and with a helpful
error message when the necessary metadata is missing.
* More style updates. See #656, #635, #640,
#644, #650, #652, and #655.
v24.0.3
=======
* Updated style in much of the codebase to match
community expectations. See #632, #633, #634,
#637, #639, #638, #642, #648.
v24.0.2
=======
* If MSVC++14 is needed ``setuptools.msvc`` now redirect
user to Visual C++ Build Tools web page.
v24.0.1
=======
* #625 and #626: Fixes on ``setuptools.msvc`` mainly
for Python 2 and Linux.
v24.0.0
=======
* Pull Request #174: Add more aggressive support for
standalone Microsoft Visual C++ compilers in
msvc9compiler patch.
Particularly : Windows SDK 6.1 and 7.0
(MSVC++ 9.0), Windows SDK 7.1 (MSVC++ 10.0),
Visual C++ Build Tools 2015 (MSVC++14)
* Renamed ``setuptools.msvc9_support`` to
``setuptools.msvc``.
v23.2.1
=======
Re-release of v23.2.0, which was missing the intended
commits.
* #623: Remove used of deprecated 'U' flag when reading
manifests.
v23.1.0
=======
* #619: Deprecated ``tag_svn_revision`` distribution
option.
v23.0.0
=======
* #611: Removed ARM executables for CLI and GUI script
launchers on Windows. If this was a feature you cared
about, please comment in the ticket.
* #604: Removed docs building support. The project
now relies on documentation hosted at
https://setuptools.pypa.io/.
v22.0.5
=======
* #604: Restore repository for upload_docs command
to restore publishing of docs during release.
v22.0.4
=======
* #589: Upload releases to pypi.io using the upload
hostname and legacy path.
v22.0.3
=======
* #589: Releases are now uploaded to pypi.io (Warehouse)
even when releases are made on Twine via Travis.
v22.0.2
=======
* #589: Releases are now uploaded to pypi.io (Warehouse).
v22.0.1
=======
* #190: On Python 2, if unicode is passed for packages to
``build_py`` command, it will be handled just as with
text on Python 3.
v22.0.0
=======
Intended to be v21.3.0, but jaraco accidentally released as
a major bump.
* #598: Setuptools now lists itself first in the User-Agent
for web requests, better following the guidelines in
`RFC 7231
`_.
v21.2.2
=======
* Minor fixes to changelog and docs.
v21.2.1
=======
* #261: Exclude directories when resolving globs in
package_data.
v21.2.0
=======
* #539: In the easy_install get_site_dirs, honor all
paths found in ``site.getsitepackages``.
v21.1.0
=======
* #572: In build_ext, now always import ``_CONFIG_VARS``
from ``distutils`` rather than from ``sysconfig``
to allow ``distutils.sysconfig.customize_compiler``
configure the OS X compiler for ``-dynamiclib``.
v21.0.0
=======
* Removed ez_setup.py from Setuptools sdist. The
bootstrap script will be maintained in its own
branch and should be generally be retrieved from
its canonical location at
https://bootstrap.pypa.io/ez_setup.py.
v20.10.0
========
* #553: egg_info section is now generated in a
deterministic order, matching the order generated
by earlier versions of Python. Except on Python 2.6,
order is preserved when existing settings are present.
* #556: Update to Packaging 16.7, restoring support
for deprecated ``python_implmentation`` marker.
* #555: Upload command now prompts for a password
when uploading to PyPI (or other repository) if no
password is present in .pypirc or in the keyring.
v20.9.0
=======
* #548: Update certify version to 2016.2.28
* #545: Safely handle deletion of non-zip eggs in rotate
command.
v20.8.1
=======
* Issue #544: Fix issue with extra environment marker
processing in WorkingSet due to refactor in v20.7.0.
v20.8.0
=======
* Issue #543: Re-release so that latest release doesn't
cause déjà vu with distribute and setuptools 0.7 in
older environments.
v20.7.0
=======
* Refactored extra environment marker processing
in WorkingSet.
* Issue #533: Fixed intermittent test failures.
* Issue #536: In msvc9_support, trap additional exceptions
that might occur when importing
``distutils.msvc9compiler`` in mingw environments.
* Issue #537: Provide better context when package
metadata fails to decode in UTF-8.
v20.6.8
=======
* Issue #523: Restored support for environment markers,
now honoring 'extra' environment markers.
v20.6.7
=======
* Issue #523: Disabled support for environment markers
introduced in v20.5.
v20.6.6
=======
* Issue #503: Restore support for PEP 345 environment
markers by updating to Packaging 16.6.
v20.6.0
=======
* New release process that relies on
`bumpversion `_
and Travis CI for continuous deployment.
* Project versioning semantics now follow
`semver `_ precisely.
The 'v' prefix on version numbers now also allows
version numbers to be referenced in the changelog,
e.g. http://setuptools.pypa.io/en/latest/history.html#v20-6-0.
20.5
====
* BB Pull Request #185, #470: Add support for environment markers
in requirements in install_requires, setup_requires,
tests_require as well as adding a test for the existing
extra_requires machinery.
20.4
====
* Issue #422: Moved hosting to
`Github `_
from `Bitbucket `_.
Issues have been migrated, though all issues and comments
are attributed to bb-migration. So if you have a particular
issue or issues to which you've been subscribed, you will
want to "watch" the equivalent issue in Github.
The Bitbucket project will be retained for the indefinite
future, but Github now hosts the canonical project repository.
20.3.1
======
* Issue #519: Remove import hook when reloading the
``pkg_resources`` module.
* BB Pull Request #184: Update documentation in ``pkg_resources``
around new ``Requirement`` implementation.
20.3
====
* BB Pull Request #179: ``pkg_resources.Requirement`` objects are
now a subclass of ``packaging.requirements.Requirement``,
allowing any environment markers and url (if any) to be
affiliated with the requirement
* BB Pull Request #179: Restore use of RequirementParseError
exception unintentionally dropped in 20.2.
20.2.2
======
* Issue #502: Correct regression in parsing of multiple
version specifiers separated by commas and spaces.
20.2.1
======
* Issue #499: Restore compatibility for legacy versions
by bumping to packaging 16.4.
20.2
====
* Changelog now includes release dates and links to PEPs.
* BB Pull Request #173: Replace dual PEP 345 _markerlib implementation
and PEP 426 implementation of environment marker support from
packaging 16.1 and PEP 508. Fixes Issue #122.
See also BB Pull Request #175, BB Pull Request #168, and
BB Pull Request #164. Additionally:
- ``Requirement.parse`` no longer retains the order of extras.
- ``parse_requirements`` now requires that all versions be
PEP-440 compliant, as revealed in #499. Packages released
with invalid local versions should be re-released using
the proper local version syntax, e.g. ``mypkg-1.0+myorg.1``.
20.1.1
======
* Update ``upload_docs`` command to also honor keyring
for password resolution.
20.1
====
* Added support for using passwords from keyring in the upload
command. See `the upload docs
`_
for details.
20.0
====
* Issue #118: Once again omit the package metadata (egg-info)
from the list of outputs in ``--record``. This version of setuptools
can no longer be used to upgrade pip earlier than 6.0.
19.7
====
* Off-project PR: `0dcee79 `_ and `f9bd9b9 `_
For FreeBSD, also `honor root certificates from ca_root_nss `_.
19.6.2
======
* Issue #491: Correct regression incurred in 19.4 where
a double-namespace package installed using pip would
cause a TypeError.
19.6.1
======
* Restore compatibility for PyPy 3 compatibility lost in
19.4.1 addressing Issue #487.
* ``setuptools.launch`` shim now loads scripts in a new
namespace, avoiding getting relative imports from
the setuptools package on Python 2.
19.6
====
* Added a new entry script ``setuptools.launch``,
implementing the shim found in
``pip.util.setuptools_build``. Use this command to launch
distutils-only packages under setuptools in the same way that
pip does, causing the setuptools monkeypatching of distutils
to be invoked prior to invoking a script. Useful for debugging
or otherwise installing a distutils-only package under
setuptools when pip isn't available or otherwise does not
expose the desired functionality. For example::
$ python -m setuptools.launch setup.py develop
* Issue #488: Fix dual manifestation of Extension class in
extension packages installed as dependencies when Cython
is present.
19.5
====
* Issue #486: Correct TypeError when getfilesystemencoding
returns None.
* Issue #139: Clarified the license as MIT.
* BB Pull Request #169: Removed special handling of command
spec in scripts for Jython.
19.4.1
======
* Issue #487: Use direct invocation of ``importlib.machinery``
in ``pkg_resources`` to avoid missing detection on relevant
platforms.
19.4
====
* Issue #341: Correct error in path handling of package data
files in ``build_py`` command when package is empty.
* Distribute #323, Issue #141, Issue #207, and
BB Pull Request #167: Another implementation of
``pkg_resources.WorkingSet`` and ``pkg_resources.Distribution``
that supports replacing an extant package with a new one,
allowing for setup_requires dependencies to supersede installed
packages for the session.
19.3
====
* Issue #229: Implement new technique for readily incorporating
dependencies conditionally from vendored copies or primary
locations. Adds a new dependency on six.
19.2
====
* BB Pull Request #163: Add get_command_list method to Distribution.
* BB Pull Request #162: Add missing whitespace to multiline string
literals.
19.1.1
======
* Issue #476: Cast version to string (using default encoding)
to avoid creating Unicode types on Python 2 clients.
* Issue #477: In Powershell downloader, use explicit rendering
of strings, rather than rely on ``repr``, which can be
incorrect (especially on Python 2).
19.1
====
* Issue #215: The bootstrap script ``ez_setup.py`` now
automatically detects
the latest version of setuptools (using PyPI JSON API) rather
than hard-coding a particular value.
* Issue #475: Fix incorrect usage in _translate_metadata2.
19.0
====
* Issue #442: Use RawConfigParser for parsing .pypirc file.
Interpolated values are no longer honored in .pypirc files.
18.8.1
======
* Issue #440: Prevent infinite recursion when a SandboxViolation
or other UnpickleableException occurs in a sandbox context
with setuptools hidden. Fixes regression introduced in Setuptools
12.0.
18.8
====
* Deprecated ``egg_info.get_pkg_info_revision``.
* Issue #471: Don't rely on repr for an HTML attribute value in
package_index.
* Issue #419: Avoid errors in FileMetadata when the metadata directory
is broken.
* Issue #472: Remove deprecated use of 'U' in mode parameter
when opening files.
18.7.1
======
* Issue #469: Refactored logic for Issue #419 fix to re-use metadata
loading from Provider.
18.7
====
* Update dependency on certify.
* BB Pull Request #160: Improve detection of gui script in
``easy_install._adjust_header``.
* Made ``test.test_args`` a non-data property; alternate fix
for the issue reported in BB Pull Request #155.
* Issue #453: In ``ez_setup`` bootstrap module, unload all
``pkg_resources`` modules following download.
* BB Pull Request #158: Honor PEP-488 when excluding
files for namespace packages.
* Issue #419 and BB Pull Request #144: Add experimental support for
reading the version info from distutils-installed metadata rather
than using the version in the filename.
18.6.1
======
* Issue #464: Correct regression in invocation of superclass on old-style
class on Python 2.
18.6
====
* Issue #439: When installing entry_point scripts under development,
omit the version number of the package, allowing any version of the
package to be used.
18.5
====
* In preparation for dropping support for Python 3.2, a warning is
now logged when pkg_resources is imported on Python 3.2 or earlier
Python 3 versions.
* `Add support for python_platform_implementation environment marker
`_.
* `Fix dictionary mutation during iteration
`_.
18.4
====
* Issue #446: Test command now always invokes unittest, even
if no test suite is supplied.
18.3.2
======
* Correct another regression in setuptools.findall
where the fix for Python #12885 was lost.
18.3.1
======
* Issue #425: Correct regression in setuptools.findall.
18.3
====
* BB Pull Request #135: Setuptools now allows disabling of
the manipulation of the sys.path
during the processing of the easy-install.pth file. To do so, set
the environment variable ``SETUPTOOLS_SYS_PATH_TECHNIQUE`` to
anything but "rewrite" (consider "raw"). During any install operation
with manipulation disabled, setuptools packages will be appended to
sys.path naturally.
Future versions may change the default behavior to disable
manipulation. If so, the default behavior can be retained by setting
the variable to "rewrite".
* Issue #257: ``easy_install --version`` now shows more detail
about the installation location and Python version.
* Refactor setuptools.findall in preparation for re-submission
back to distutils.
18.2
====
* Issue #412: More efficient directory search in ``find_packages``.
18.1
====
* Upgrade to vendored packaging 15.3.
18.0.1
======
* Issue #401: Fix failure in test suite.
18.0
====
* Dropped support for builds with Pyrex. Only Cython is supported.
* Issue #288: Detect Cython later in the build process, after
``setup_requires`` dependencies are resolved.
Projects backed by Cython can now be readily built
with a ``setup_requires`` dependency. For example::
ext = setuptools.Extension('mylib', ['src/CythonStuff.pyx', 'src/CStuff.c'])
setuptools.setup(
...
ext_modules=[ext],
setup_requires=['cython'],
)
For compatibility with older versions of setuptools, packagers should
still include ``src/CythonMod.c`` in the source distributions or
require that Cython be present before building source distributions.
However, for systems with this build of setuptools, Cython will be
downloaded on demand.
* Issue #396: Fixed test failure on OS X.
* BB Pull Request #136: Remove excessive quoting from shebang headers
for Jython.
17.1.1
======
* Backed out unintended changes to pkg_resources, restoring removal of
deprecated imp module (`ref
`_).
17.1
====
* Issue #380: Add support for range operators on environment
marker evaluation.
17.0
====
* Issue #378: Do not use internal importlib._bootstrap module.
* Issue #390: Disallow console scripts with path separators in
the name. Removes unintended functionality and brings behavior
into parity with pip.
16.0
====
* BB Pull Request #130: Better error messages for errors in
parsed requirements.
* BB Pull Request #133: Removed ``setuptools.tests`` from the
installed packages.
* BB Pull Request #129: Address deprecation warning due to usage
of imp module.
15.2
====
* Issue #373: Provisionally expose
``pkg_resources._initialize_master_working_set``, allowing for
imperative re-initialization of the master working set.
15.1
====
* Updated to Packaging 15.1 to address Packaging #28.
* Fix ``setuptools.sandbox._execfile()`` with Python 3.1.
15.0
====
* BB Pull Request #126: DistributionNotFound message now lists the package or
packages that required it. E.g.::
pkg_resources.DistributionNotFound: The 'colorama>=0.3.1' distribution was not found and is required by smlib.log.
Note that zc.buildout once dependended on the string rendering of this
message to determine the package that was not found. This expectation
has since been changed, but older versions of buildout may experience
problems. See Buildout #242 for details.
14.3.1
======
* Issue #307: Removed PEP-440 warning during parsing of versions
in ``pkg_resources.Distribution``.
* Issue #364: Replace deprecated usage with recommended usage of
``EntryPoint.load``.
14.3
====
* Issue #254: When creating temporary egg cache on Unix, use mode 755
for creating the directory to avoid the subsequent warning if
the directory is group writable.
14.2
====
* Issue #137: Update ``Distribution.hashcmp`` so that Distributions with
None for pyversion or platform can be compared against Distributions
defining those attributes.
14.1.1
======
* Issue #360: Removed undesirable behavior from test runs, preventing
write tests and installation to system site packages.
14.1
====
* BB Pull Request #125: Add ``__ne__`` to Requirement class.
* Various refactoring of easy_install.
14.0
====
* Bootstrap script now accepts ``--to-dir`` to customize save directory or
allow for re-use of existing repository of setuptools versions. See
BB Pull Request #112 for background.
* Issue #285: ``easy_install`` no longer will default to installing
packages to the "user site packages" directory if it is itself installed
there. Instead, the user must pass ``--user`` in all cases to install
packages to the user site packages.
This behavior now matches that of "pip install". To configure
an environment to always install to the user site packages, consider
using the "install-dir" and "scripts-dir" parameters to easy_install
through an appropriate distutils config file.
13.0.2
======
* Issue #359: Include pytest.ini in the sdist so invocation of py.test on the
sdist honors the pytest configuration.
13.0.1
======
Re-release of 13.0. Intermittent connectivity issues caused the release
process to fail and PyPI uploads no longer accept files for 13.0.
13.0
====
* Issue #356: Back out BB Pull Request #119 as it requires Setuptools 10 or later
as the source during an upgrade.
* Removed build_py class from setup.py. According to 892f439d216e, this
functionality was added to support upgrades from old Distribute versions,
0.6.5 and 0.6.6.
12.4
====
* BB Pull Request #119: Restore writing of ``setup_requires`` to metadata
(previously added in 8.4 and removed in 9.0).
12.3
====
* Documentation is now linked using the rst.linker package.
* Fix ``setuptools.command.easy_install.extract_wininst_cfg()``
with Python 2.6 and 2.7.
* Issue #354. Added documentation on building setuptools
documentation.
12.2
====
* Issue #345: Unload all modules under pkg_resources during
``ez_setup.use_setuptools()``.
* Issue #336: Removed deprecation from ``ez_setup.use_setuptools``,
as it is clearly still used by buildout's bootstrap. ``ez_setup``
remains deprecated for use by individual packages.
* Simplified implementation of ``ez_setup.use_setuptools``.
12.1
====
* BB Pull Request #118: Soften warning for non-normalized versions in
Distribution.
12.0.5
======
* Issue #339: Correct Attribute reference in ``cant_write_to_target``.
* Issue #336: Deprecated ``ez_setup.use_setuptools``.
12.0.4
======
* Issue #335: Fix script header generation on Windows.
12.0.3
======
* Fixed incorrect class attribute in ``install_scripts``. Tests would be nice.
12.0.2
======
* Issue #331: Fixed ``install_scripts`` command on Windows systems corrupting
the header.
12.0.1
======
* Restore ``setuptools.command.easy_install.sys_executable`` for pbr
compatibility. For the future, tools should construct a CommandSpec
explicitly.
12.0
====
* Issue #188: Setuptools now support multiple entities in the value for
``build.executable``, such that an executable of "/usr/bin/env my-python" may
be specified. This means that systems with a specified executable whose name
has spaces in the path must be updated to escape or quote that value.
* Deprecated ``easy_install.ScriptWriter.get_writer``, replaced by ``.best()``
with slightly different semantics (no force_windows flag).
11.3.1
======
* Issue #327: Formalize and restore support for any printable character in an
entry point name.
11.3
====
* Expose ``EntryPoint.resolve`` in place of EntryPoint._load, implementing the
simple, non-requiring load. Deprecated all uses of ``EntryPoint._load``
except for calling with no parameters, which is just a shortcut for
``ep.require(); ep.resolve();``.
Apps currently invoking ``ep.load(require=False)`` should instead do the
following if wanting to avoid the deprecating warning::
getattr(ep, "resolve", lambda: ep.load(require=False))()
11.2
====
* Pip #2326: Report deprecation warning at stacklevel 2 for easier diagnosis.
11.1
====
* Issue #281: Since Setuptools 6.1 (Issue #268), a ValueError would be raised
in certain cases where VersionConflict was raised with two arguments, which
occurred in ``pkg_resources.WorkingSet.find``. This release adds support
for indicating the dependent packages while maintaining support for
a VersionConflict when no dependent package context is known. New unit tests
now capture the expected interface.
11.0
====
* Interop #3: Upgrade to Packaging 15.0; updates to PEP 440 so that >1.7 does
not exclude 1.7.1 but does exclude 1.7.0 and 1.7.0.post1.
10.2.1
======
* Issue #323: Fix regression in entry point name parsing.
10.2
====
* Deprecated use of EntryPoint.load(require=False). Passing a boolean to a
function to select behavior is an anti-pattern. Instead use
``Entrypoint._load()``.
* Substantial refactoring of all unit tests. Tests are now much leaner and
re-use a lot of fixtures and contexts for better clarity of purpose.
10.1
====
* Issue #320: Added a compatibility implementation of
``sdist._default_revctrl``
so that systems relying on that interface do not fail (namely, Ubuntu 12.04
and similar Debian releases).
10.0.1
======
* Issue #319: Fixed issue installing pure distutils packages.
10.0
====
* Issue #313: Removed built-in support for subversion. Projects wishing to
retain support for subversion will need to use a third party library. The
extant implementation is being ported to :pypi:`setuptools_svn`.
* Issue #315: Updated setuptools to hide its own loaded modules during
installation of another package. This change will enable setuptools to
upgrade (or downgrade) itself even when its own metadata and implementation
change.
9.1
===
* Prefer vendored packaging library `as recommended
`_.
9.0.1
=====
* Issue #312: Restored presence of pkg_resources API tests (doctest) to sdist.
9.0
===
* Issue #314: Disabled support for ``setup_requires`` metadata to avoid issue
where Setuptools was unable to upgrade over earlier versions.
8.4
===
* BB Pull Request #106: Now write ``setup_requires`` metadata.
8.3
===
* Issue #311: Decoupled pkg_resources from setuptools once again.
``pkg_resources`` is now a package instead of a module.
8.2.1
=====
* Issue #306: Suppress warnings about Version format except in select scenarios
(such as installation).
8.2
===
* BB Pull Request #85: Search egg-base when adding egg-info to manifest.
8.1
===
* Upgrade ``packaging`` to 14.5, giving preference to "rc" as designator for
release candidates over "c".
* PEP-440 warnings are now raised as their own class,
``pkg_resources.PEP440Warning``, instead of RuntimeWarning.
* Disabled warnings on empty versions.
8.0.4
=====
* Upgrade ``packaging`` to 14.4, fixing an error where there is a
different result for if 2.0.5 is contained within >2.0dev and >2.0.dev even
though normalization rules should have made them equal.
* Issue #296: Add warning when a version is parsed as legacy. This warning will
make it easier for developers to recognize deprecated version numbers.
8.0.3
=====
* Issue #296: Restored support for ``__hash__`` on parse_version results.
8.0.2
=====
* Issue #296: Restored support for ``__getitem__`` and sort operations on
parse_version result.
8.0.1
=====
* Issue #296: Restore support for iteration over parse_version result, but
deprecated that usage with a warning. Fixes failure with buildout.
8.0
===
* Implement PEP 440 within
pkg_resources and setuptools. This change
deprecates some version numbers such that they will no longer be installable
without using the ``===`` escape hatch. See `the changes to test_resources
`_
for specific examples of version numbers and specifiers that are no longer
supported. Setuptools now "vendors" the `packaging
`_ library.
7.0
===
* Issue #80, Issue #209: Eggs that are downloaded for ``setup_requires``,
``test_requires``, etc. are now placed in a ``./.eggs`` directory instead of
directly in the current directory. This choice of location means the files
can be readily managed (removed, ignored). Additionally,
later phases or invocations of setuptools will not detect the package as
already installed and ignore it for permanent install (See #209).
This change is indicated as backward-incompatible as installations that
depend on the installation in the current directory will need to account for
the new location. Systems that ignore ``*.egg`` will probably need to be
adapted to ignore ``.eggs``. The files will need to be manually moved or
will be retrieved again. Most use cases will require no attention.
6.1
===
* Issue #268: When resolving package versions, a VersionConflict now reports
which package previously required the conflicting version.
6.0.2
=====
* Issue #262: Fixed regression in pip install due to egg-info directories
being omitted. Re-opens Issue #118.
6.0.1
=====
* Issue #259: Fixed regression with namespace package handling on ``single
version, externally managed`` installs.
6.0
===
* Issue #100: When building a distribution, Setuptools will no longer match
default files using platform-dependent case sensitivity, but rather will
only match the files if their case matches exactly. As a result, on Windows
and other case-insensitive file systems, files with names such as
'readme.txt' or 'README.TXT' will be omitted from the distribution and a
warning will be issued indicating that 'README.txt' was not found. Other
filenames affected are:
- README.rst
- README
- setup.cfg
- setup.py (or the script name)
- test/test*.py
Any users producing distributions with filenames that match those above
case-insensitively, but not case-sensitively, should rename those files in
their repository for better portability.
* BB Pull Request #72: When using ``single_version_externally_managed``, the
exclusion list now includes Python 3.2 ``__pycache__`` entries.
* BB Pull Request #76 and BB Pull Request #78: lines in top_level.txt are now
ordered deterministically.
* Issue #118: The egg-info directory is now no longer included in the list
of outputs.
* Issue #258: Setuptools now patches distutils msvc9compiler to
recognize the specially-packaged compiler package for easy extension module
support on Python 2.6, 2.7, and 3.2.
5.8
===
* Issue #237: ``pkg_resources`` now uses explicit detection of Python 2 vs.
Python 3, supporting environments where builtins have been patched to make
Python 3 look more like Python 2.
5.7
===
* Issue #240: Based on real-world performance measures against 5.4, zip
manifests are now cached in all circumstances. The
``PKG_RESOURCES_CACHE_ZIP_MANIFESTS`` environment variable is no longer
relevant. The observed "memory increase" referenced in the 5.4 release
notes and detailed in Issue #154 was likely not an increase over the status
quo, but rather only an increase over not storing the zip info at all.
5.6
===
* Issue #242: Use absolute imports in svn_utils to avoid issues if the
installing package adds an xml module to the path.
5.5.1
=====
* Issue #239: Fix typo in 5.5 such that fix did not take.
5.5
===
* Issue #239: Setuptools now includes the setup_requires directive on
Distribution objects and validates the syntax just like install_requires
and tests_require directives.
5.4.2
=====
* Issue #236: Corrected regression in execfile implementation for Python 2.6.
5.4.1
=====
* Python #7776: (ssl_support) Correct usage of host for validation when
tunneling for HTTPS.
5.4
===
* Issue #154: ``pkg_resources`` will now cache the zip manifests rather than
re-processing the same file from disk multiple times, but only if the
environment variable ``PKG_RESOURCES_CACHE_ZIP_MANIFESTS`` is set. Clients
that package many modules in the same zip file will see some improvement
in startup time by enabling this feature. This feature is not enabled by
default because it causes a substantial increase in memory usage.
5.3
===
* Issue #185: Make svn tagging work on the new style SVN metadata.
Thanks cazabon!
* Prune revision control directories (e.g .svn) from base path
as well as sub-directories.
5.2
===
* Added a `Developer Guide
`_ to the official
documentation.
* Some code refactoring and cleanup was done with no intended behavioral
changes.
* During install_egg_info, the generated lines for namespace package .pth
files are now processed even during a dry run.
5.1
===
* Issue #202: Implemented more robust cache invalidation for the ZipImporter,
building on the work in Issue #168. Special thanks to Jurko Gospodnetic and
PJE.
5.0.2
=====
* Issue #220: Restored script templates.
5.0.1
=====
* Renamed script templates to end with .tmpl now that they no longer need
to be processed by 2to3. Fixes spurious syntax errors during build/install.
5.0
===
* Issue #218: Re-release of 3.8.1 to signal that it supersedes 4.x.
* Incidentally, script templates were updated not to include the triple-quote
escaping.
3.7.1 and 3.8.1 and 4.0.1
=========================
* Issue #213: Use legacy StringIO behavior for compatibility under pbr.
* Issue #218: Setuptools 3.8.1 superseded 4.0.1, and 4.x was removed
from the available versions to install.
4.0
===
* Issue #210: ``setup.py develop`` now copies scripts in binary mode rather
than text mode, matching the behavior of the ``install`` command.
3.8
===
* Extend Issue #197 workaround to include all Python 3 versions prior to
3.2.2.
3.7
===
* Issue #193: Improved handling of Unicode filenames when building manifests.
3.6
===
* Issue #203: Honor proxy settings for Powershell downloader in the bootstrap
routine.
3.5.2
=====
* Issue #168: More robust handling of replaced zip files and stale caches.
Fixes ZipImportError complaining about a 'bad local header'.
3.5.1
=====
* Issue #199: Restored ``install._install`` for compatibility with earlier
NumPy versions.
3.5
===
* Issue #195: Follow symbolic links in find_packages (restoring behavior
broken in 3.4).
* Issue #197: On Python 3.1, PKG-INFO is now saved in a UTF-8 encoding instead
of ``sys.getpreferredencoding`` to match the behavior on Python 2.6-3.4.
* Issue #192: Preferred bootstrap location is now
https://bootstrap.pypa.io/ez_setup.py (mirrored from former location).
3.4.4
=====
* Issue #184: Correct failure where find_package over-matched packages
when directory traversal isn't short-circuited.
3.4.3
=====
* Issue #183: Really fix test command with Python 3.1.
3.4.2
=====
* Issue #183: Fix additional regression in test command on Python 3.1.
3.4.1
=====
* Issue #180: Fix regression in test command not caught by py.test-run tests.
3.4
===
* Issue #176: Add parameter to the test command to support a custom test
runner: --test-runner or -r.
* Issue #177: Now assume most common invocation to install command on
platforms/environments without stack support (issuing a warning). Setuptools
now installs naturally on IronPython. Behavior on CPython should be
unchanged.
3.3
===
* Add ``include`` parameter to ``setuptools.find_packages()``.
3.2
===
* BB Pull Request #39: Add support for C++ targets from Cython ``.pyx`` files.
* Issue #162: Update dependency on certifi to 1.0.1.
* Issue #164: Update dependency on wincertstore to 0.2.
3.1
===
* Issue #161: Restore Features functionality to allow backward compatibility
(for Features) until the uses of that functionality is sufficiently removed.
3.0.2
=====
* Correct typo in previous bugfix.
3.0.1
=====
* Issue #157: Restore support for Python 2.6 in bootstrap script where
``zipfile.ZipFile`` does not yet have support for context managers.
3.0
===
* Issue #125: Prevent Subversion support from creating a ~/.subversion
directory just for checking the presence of a Subversion repository.
* Issue #12: Namespace packages are now imported lazily. That is, the mere
declaration of a namespace package in an egg on ``sys.path`` no longer
causes it to be imported when ``pkg_resources`` is imported. Note that this
change means that all of a namespace package's ``__init__.py`` files must
include a ``declare_namespace()`` call in order to ensure that they will be
handled properly at runtime. In 2.x it was possible to get away without
including the declaration, but only at the cost of forcing namespace
packages to be imported early, which 3.0 no longer does.
* Issue #148: When building (bdist_egg), setuptools no longer adds
``__init__.py`` files to namespace packages. Any packages that rely on this
behavior will need to create ``__init__.py`` files and include the
``declare_namespace()``.
* Issue #7: Setuptools itself is now distributed as a zip archive in addition to
tar archive. ez_setup.py now uses zip archive. This approach avoids the potential
security vulnerabilities presented by use of tar archives in ez_setup.py.
It also leverages the security features added to ZipFile.extract in Python 2.7.4.
* Issue #65: Removed deprecated Features functionality.
* BB Pull Request #28: Remove backport of ``_bytecode_filenames`` which is
available in Python 2.6 and later, but also has better compatibility with
Python 3 environments.
* Issue #156: Fix spelling of __PYVENV_LAUNCHER__ variable.
2.2
===
* Issue #141: Restored fix for allowing setup_requires dependencies to
override installed dependencies during setup.
* Issue #128: Fixed issue where only the first dependency link was honored
in a distribution where multiple dependency links were supplied.
2.1.2
=====
* Issue #144: Read long_description using codecs module to avoid errors
installing on systems where LANG=C.
2.1.1
=====
* Issue #139: Fix regression in re_finder for CVS repos (and maybe Git repos
as well).
2.1
===
* Issue #129: Suppress inspection of ``*.whl`` files when searching for files
in a zip-imported file.
* Issue #131: Fix RuntimeError when constructing an egg fetcher.
2.0.2
=====
* Fix NameError during installation with Python implementations (e.g. Jython)
not containing parser module.
* Fix NameError in ``sdist:re_finder``.
2.0.1
=====
* Issue #124: Fixed error in list detection in upload_docs.
2.0
===
* Issue #121: Exempt lib2to3 pickled grammars from DirectorySandbox.
* Issue #41: Dropped support for Python 2.4 and Python 2.5. Clients requiring
setuptools for those versions of Python should use setuptools 1.x.
* Removed ``setuptools.command.easy_install.HAS_USER_SITE``. Clients
expecting this boolean variable should use ``site.ENABLE_USER_SITE``
instead.
* Removed ``pkg_resources.ImpWrapper``. Clients that expected this class
should use ``pkgutil.ImpImporter`` instead.
1.4.2
=====
* Issue #116: Correct TypeError when reading a local package index on Python
3.
1.4.1
=====
* Issue #114: Use ``sys.getfilesystemencoding`` for decoding config in
``bdist_wininst`` distributions.
* Issue #105 and Issue #113: Establish a more robust technique for
determining the terminal encoding::
1. Try ``getpreferredencoding``
2. If that returns US_ASCII or None, try the encoding from
``getdefaultlocale``. If that encoding was a "fallback" because Python
could not figure it out from the environment or OS, encoding remains
unresolved.
3. If the encoding is resolved, then make sure Python actually implements
the encoding.
4. On the event of an error or unknown codec, revert to fallbacks
(UTF-8 on Darwin, ASCII on everything else).
5. On the encoding is 'mac-roman' on Darwin, use UTF-8 as 'mac-roman' was
a bug on older Python releases.
On a side note, it would seem that the encoding only matters for when SVN
does not yet support ``--xml`` and when getting repository and svn version
numbers. The ``--xml`` technique should yield UTF-8 according to some
messages on the SVN mailing lists. So if the version numbers are always
7-bit ASCII clean, it may be best to only support the file parsing methods
for legacy SVN releases and support for SVN without the subprocess command
would simple go away as support for the older SVNs does.
1.4
===
* Issue #27: ``easy_install`` will now use credentials from .pypirc if
present for connecting to the package index.
* BB Pull Request #21: Omit unwanted newlines in ``package_index._encode_auth``
when the username/password pair length indicates wrapping.
1.3.2
=====
* Issue #99: Fix filename encoding issues in SVN support.
1.3.1
=====
* Remove exuberant warning in SVN support when SVN is not used.
1.3
===
* Address security vulnerability in SSL match_hostname check as reported in
Python #17997.
* Prefer :pypi:`backports.ssl_match_hostname` for backport
implementation if present.
* Correct NameError in ``ssl_support`` module (``socket.error``).
1.2
===
* Issue #26: Add support for SVN 1.7. Special thanks to Philip Thiem for the
contribution.
* Issue #93: Wheels are now distributed with every release. Note that as
reported in Issue #108, as of Pip 1.4, scripts aren't installed properly
from wheels. Therefore, if using Pip to install setuptools from a wheel,
the ``easy_install`` command will not be available.
* Setuptools "natural" launcher support, introduced in 1.0, is now officially
supported.
1.1.7
=====
* Fixed behavior of NameError handling in 'script template (dev).py' (script
launcher for 'develop' installs).
* ``ez_setup.py`` now ensures partial downloads are cleaned up following
a failed download.
* Distribute #363 and Issue #55: Skip an sdist test that fails on locales
other than UTF-8.
1.1.6
=====
* Distribute #349: ``sandbox.execfile`` now opens the target file in binary
mode, thus honoring a BOM in the file when compiled.
1.1.5
=====
* Issue #69: Second attempt at fix (logic was reversed).
1.1.4
=====
* Issue #77: Fix error in upload command (Python 2.4).
1.1.3
=====
* Fix NameError in previous patch.
1.1.2
=====
* Issue #69: Correct issue where 404 errors are returned for URLs with
fragments in them (such as #egg=).
1.1.1
=====
* Issue #75: Add ``--insecure`` option to ez_setup.py to accommodate
environments where a trusted SSL connection cannot be validated.
* Issue #76: Fix AttributeError in upload command with Python 2.4.
1.1
===
* Issue #71 (Distribute #333): EasyInstall now puts less emphasis on the
condition when a host is blocked via ``--allow-hosts``.
* Issue #72: Restored Python 2.4 compatibility in ``ez_setup.py``.
1.0
===
* Issue #60: On Windows, Setuptools supports deferring to another launcher,
such as Vinay Sajip's `pylauncher `_
(included with Python 3.3) to launch console and GUI scripts and not install
its own launcher executables. This experimental functionality is currently
only enabled if the ``SETUPTOOLS_LAUNCHER`` environment variable is set to
"natural". In the future, this behavior may become default, but only after
it has matured and seen substantial adoption. The ``SETUPTOOLS_LAUNCHER``
also accepts "executable" to force the default behavior of creating launcher
executables.
* Issue #63: Bootstrap script (ez_setup.py) now prefers Powershell, curl, or
wget for retrieving the Setuptools tarball for improved security of the
install. The script will still fall back to a simple ``urlopen`` on
platforms that do not have these tools.
* Issue #65: Deprecated the ``Features`` functionality.
* Issue #52: In ``VerifyingHTTPSConn``, handle a tunnelled (proxied)
connection.
Backward-Incompatible Changes
-----------------------------
This release includes a couple of backward-incompatible changes, but most if
not all users will find 1.0 a drop-in replacement for 0.9.
* Issue #50: Normalized API of environment marker support. Specifically,
removed line number and filename from SyntaxErrors when returned from
``pkg_resources.invalid_marker``. Any clients depending on the specific
string representation of exceptions returned by that function may need to
be updated to account for this change.
* Issue #50: SyntaxErrors generated by ``pkg_resources.invalid_marker`` are
normalized for cross-implementation consistency.
* Removed ``--ignore-conflicts-at-my-risk`` and ``--delete-conflicting``
options to easy_install. These options have been deprecated since 0.6a11.
0.9.8
=====
* Issue #53: Fix NameErrors in ``_vcs_split_rev_from_url``.
0.9.7
=====
* Issue #49: Correct AttributeError on PyPy where a hashlib.HASH object does
not have a ``.name`` attribute.
* Issue #34: Documentation now refers to bootstrap script in code repository
referenced by bookmark.
* Add underscore-separated keys to environment markers (markerlib).
0.9.6
=====
* Issue #44: Test failure on Python 2.4 when MD5 hash doesn't have a ``.name``
attribute.
0.9.5
=====
* Python #17980: Fix security vulnerability in SSL certificate validation.
0.9.4
=====
* Issue #43: Fix issue (introduced in 0.9.1) with version resolution when
upgrading over other releases of Setuptools.
0.9.3
=====
* Issue #42: Fix new ``AttributeError`` introduced in last fix.
0.9.2
=====
* Issue #42: Fix regression where blank checksums would trigger an
``AttributeError``.
0.9.1
=====
* Distribute #386: Allow other positional and keyword arguments to os.open.
* Corrected dependency on certifi mis-referenced in 0.9.
0.9
===
* ``package_index`` now validates hashes other than MD5 in download links.
0.8
===
* Code base now runs on Python 2.4 - Python 3.3 without Python 2to3
conversion.
0.7.8
=====
* Distribute #375: Yet another fix for yet another regression.
0.7.7
=====
* Distribute #375: Repair AttributeError created in last release (redo).
* Issue #30: Added test for get_cache_path.
0.7.6
=====
* Distribute #375: Repair AttributeError created in last release.
0.7.5
=====
* Issue #21: Restore Python 2.4 compatibility in ``test_easy_install``.
* Distribute #375: Merged additional warning from Distribute 0.6.46.
* Now honor the environment variable
``SETUPTOOLS_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT`` in addition to the now
deprecated ``DISTRIBUTE_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT``.
0.7.4
=====
* Issue #20: Fix comparison of parsed SVN version on Python 3.
0.7.3
=====
* Issue #1: Disable installation of Windows-specific files on non-Windows systems.
* Use new sysconfig module with Python 2.7 or >=3.2.
0.7.2
=====
* Issue #14: Use markerlib when the ``parser`` module is not available.
* Issue #10: ``ez_setup.py`` now uses HTTPS to download setuptools from PyPI.
0.7.1
=====
* Fix NameError (Issue #3) again - broken in bad merge.
0.7
===
* Merged Setuptools and Distribute. See docs/merge.txt for details.
Added several features that were slated for setuptools 0.6c12:
* Index URL now defaults to HTTPS.
* Added experimental environment marker support. Now clients may designate a
PEP-426 environment marker for "extra" dependencies. Setuptools uses this
feature in ``setup.py`` for optional SSL and certificate validation support
on older platforms. Based on Distutils-SIG discussions, the syntax is
somewhat tentative. There should probably be a PEP with a firmer spec before
the feature should be considered suitable for use.
* Added support for SSL certificate validation when installing packages from
an HTTPS service.
0.7b4
=====
* Issue #3: Fixed NameError in SSL support.
0.6.49
======
* Move warning check in ``get_cache_path`` to follow the directory creation
to avoid errors when the cache path does not yet exist. Fixes the error
reported in Distribute #375.
0.6.48
======
* Correct AttributeError in ``ResourceManager.get_cache_path`` introduced in
0.6.46 (redo).
0.6.47
======
* Correct AttributeError in ``ResourceManager.get_cache_path`` introduced in
0.6.46.
0.6.46
======
* Distribute #375: Issue a warning if the PYTHON_EGG_CACHE or otherwise
customized egg cache location specifies a directory that's group- or
world-writable.
0.6.45
======
* Distribute #379: ``distribute_setup.py`` now traps VersionConflict as well,
restoring ability to upgrade from an older setuptools version.
0.6.44
======
* ``distribute_setup.py`` has been updated to allow Setuptools 0.7 to
satisfy use_setuptools.
0.6.43
======
* Distribute #378: Restore support for Python 2.4 Syntax (regression in 0.6.42).
0.6.42
======
* External links finder no longer yields duplicate links.
* Distribute #337: Moved site.py to setuptools/site-patch.py (graft of very old
patch from setuptools trunk which inspired PR #31).
0.6.41
======
* Distribute #27: Use public api for loading resources from zip files rather than
the private method ``_zip_directory_cache``.
* Added a new function ``easy_install.get_win_launcher`` which may be used by
third-party libraries such as buildout to get a suitable script launcher.
0.6.40
======
* Distribute #376: brought back cli.exe and gui.exe that were deleted in the
previous release.
0.6.39
======
* Add support for console launchers on ARM platforms.
* Fix possible issue in GUI launchers where the subsystem was not supplied to
the linker.
* Launcher build script now refactored for robustness.
* Distribute #375: Resources extracted from a zip egg to the file system now also
check the contents of the file against the zip contents during each
invocation of get_resource_filename.
0.6.38
======
* Distribute #371: The launcher manifest file is now installed properly.
0.6.37
======
* Distribute #143: Launcher scripts, including easy_install itself, are now
accompanied by a manifest on 32-bit Windows environments to avoid the
Installer Detection Technology and thus undesirable UAC elevation described
in `this Microsoft article
`_.
0.6.36
======
* BB Pull Request #35: In Buildout #64, it was reported that
under Python 3, installation of distutils scripts could attempt to copy
the ``__pycache__`` directory as a file, causing an error, apparently only
under Windows. Easy_install now skips all directories when processing
metadata scripts.
0.6.35
======
Note this release is backward-incompatible with distribute 0.6.23-0.6.34 in
how it parses version numbers.
* Distribute #278: Restored compatibility with distribute 0.6.22 and setuptools
0.6. Updated the documentation to match more closely with the version
parsing as intended in setuptools 0.6.
0.6.34
======
* Distribute #341: 0.6.33 fails to build under Python 2.4.
0.6.33
======
* Fix 2 errors with Jython 2.5.
* Fix 1 failure with Jython 2.5 and 2.7.
* Disable workaround for Jython scripts on Linux systems.
* Distribute #336: ``setup.py`` no longer masks failure exit code when tests fail.
* Fix issue in pkg_resources where try/except around a platform-dependent
import would trigger hook load failures on Mercurial. See pull request 32
for details.
* Distribute #341: Fix a ResourceWarning.
0.6.32
======
* Fix test suite with Python 2.6.
* Fix some DeprecationWarnings and ResourceWarnings.
* Distribute #335: Backed out ``setup_requires`` superseding installed requirements
until regression can be addressed.
0.6.31
======
* Distribute #303: Make sure the manifest only ever contains UTF-8 in Python 3.
* Distribute #329: Properly close files created by tests for compatibility with
Jython.
* Work around Jython #1980 and Jython #1981.
* Distribute #334: Provide workaround for packages that reference ``sys.__stdout__``
such as numpy does. This change should address pypa/virtualenv#359 as long
as the system encoding is UTF-8 or the IO encoding is specified in the
environment, i.e.::
PYTHONIOENCODING=utf8 pip install numpy
* Fix for encoding issue when installing from Windows executable on Python 3.
* Distribute #323: Allow ``setup_requires`` requirements to supersede installed
requirements. Added some new keyword arguments to existing pkg_resources
methods. Also had to updated how __path__ is handled for namespace packages
to ensure that when a new egg distribution containing a namespace package is
placed on sys.path, the entries in __path__ are found in the same order they
would have been in had that egg been on the path when pkg_resources was
first imported.
0.6.30
======
* Distribute #328: Clean up temporary directories in distribute_setup.py.
* Fix fatal bug in distribute_setup.py.
0.6.29
======
* BB Pull Request #14: Honor file permissions in zip files.
* Distribute #327: Merged pull request #24 to fix a dependency problem with pip.
* Merged pull request #23 to fix pypa/virtualenv#301.
* If Sphinx is installed, the ``upload_docs`` command now runs ``build_sphinx``
to produce uploadable documentation.
* Distribute #326: ``upload_docs`` provided mangled auth credentials under Python 3.
* Distribute #320: Fix check for "creatable" in distribute_setup.py.
* Distribute #305: Remove a warning that was triggered during normal operations.
* Distribute #311: Print metadata in UTF-8 independent of platform.
* Distribute #303: Read manifest file with UTF-8 encoding under Python 3.
* Distribute #301: Allow to run tests of namespace packages when using 2to3.
* Distribute #304: Prevent import loop in site.py under Python 3.3.
* Distribute #283: Re-enable scanning of ``*.pyc`` / ``*.pyo`` files on Python 3.3.
* Distribute #299: The develop command didn't work on Python 3, when using 2to3,
as the egg link would go to the Python 2 source. Linking to the 2to3'd code
in build/lib makes it work, although you will have to rebuild the module
before testing it.
* Distribute #306: Even if 2to3 is used, we build in-place under Python 2.
* Distribute #307: Prints the full path when .svn/entries is broken.
* Distribute #313: Support for sdist subcommands (Python 2.7)
* Distribute #314: test_local_index() would fail an OS X.
* Distribute #310: Non-ascii characters in a namespace __init__.py causes errors.
* Distribute #218: Improved documentation on behavior of ``package_data`` and
``include_package_data``. Files indicated by ``package_data`` are now included
in the manifest.
* ``distribute_setup.py`` now allows a ``--download-base`` argument for retrieving
distribute from a specified location.
0.6.28
======
* Distribute #294: setup.py can now be invoked from any directory.
* Scripts are now installed honoring the umask.
* Added support for .dist-info directories.
* Distribute #283: Fix and disable scanning of ``*.pyc`` / ``*.pyo`` files on
Python 3.3.
0.6.27
======
* Support current snapshots of CPython 3.3.
* Distribute now recognizes README.rst as a standard, default readme file.
* Exclude 'encodings' modules when removing modules from sys.modules.
Workaround for #285.
* Distribute #231: Don't fiddle with system python when used with buildout
(bootstrap.py)
0.6.26
======
* Distribute #183: Symlinked files are now extracted from source distributions.
* Distribute #227: Easy_install fetch parameters are now passed during the
installation of a source distribution; now fulfillment of setup_requires
dependencies will honor the parameters passed to easy_install.
0.6.25
======
* Distribute #258: Workaround a cache issue
* Distribute #260: distribute_setup.py now accepts the --user parameter for
Python 2.6 and later.
* Distribute #262: package_index.open_with_auth no longer throws LookupError
on Python 3.
* Distribute #269: AttributeError when an exception occurs reading Manifest.in
on late releases of Python.
* Distribute #272: Prevent TypeError when namespace package names are unicode
and single-install-externally-managed is used. Also fixes PIP issue
449.
* Distribute #273: Legacy script launchers now install with Python2/3 support.
0.6.24
======
* Distribute #249: Added options to exclude 2to3 fixers
0.6.23
======
* Distribute #244: Fixed a test
* Distribute #243: Fixed a test
* Distribute #239: Fixed a test
* Distribute #240: Fixed a test
* Distribute #241: Fixed a test
* Distribute #237: Fixed a test
* Distribute #238: easy_install now uses 64bit executable wrappers on 64bit Python
* Distribute #208: Fixed parsed_versions, it now honors post-releases as noted in the documentation
* Distribute #207: Windows cli and gui wrappers pass CTRL-C to child python process
* Distribute #227: easy_install now passes its arguments to setup.py bdist_egg
* Distribute #225: Fixed a NameError on Python 2.5, 2.4
0.6.21
======
* Distribute #225: FIxed a regression on py2.4
0.6.20
======
* Distribute #135: Include url in warning when processing URLs in package_index.
* Distribute #212: Fix issue where easy_instal fails on Python 3 on windows installer.
* Distribute #213: Fix typo in documentation.
0.6.19
======
* Distribute #206: AttributeError: 'HTTPMessage' object has no attribute 'getheaders'
0.6.18
======
* Distribute #210: Fixed a regression introduced by Distribute #204 fix.
0.6.17
======
* Support 'DISTRIBUTE_DISABLE_VERSIONED_EASY_INSTALL_SCRIPT' environment
variable to allow to disable installation of easy_install-${version} script.
* Support Python >=3.1.4 and >=3.2.1.
* Distribute #204: Don't try to import the parent of a namespace package in
declare_namespace
* Distribute #196: Tolerate responses with multiple Content-Length headers
* Distribute #205: Sandboxing doesn't preserve working_set. Leads to setup_requires
problems.
0.6.16
======
* Builds sdist gztar even on Windows (avoiding Distribute #193).
* Distribute #192: Fixed metadata omitted on Windows when package_dir
specified with forward-slash.
* Distribute #195: Cython build support.
* Distribute #200: Issues with recognizing 64-bit packages on Windows.
0.6.15
======
* Fixed typo in bdist_egg
* Several issues under Python 3 has been solved.
* Distribute #146: Fixed missing DLL files after easy_install of windows exe package.
0.6.14
======
* Distribute #170: Fixed unittest failure. Thanks to Toshio.
* Distribute #171: Fixed race condition in unittests cause deadlocks in test suite.
* Distribute #143: Fixed a lookup issue with easy_install.
Thanks to David and Zooko.
* Distribute #174: Fixed the edit mode when its used with setuptools itself
0.6.13
======
* Distribute #160: 2.7 gives ValueError("Invalid IPv6 URL")
* Distribute #150: Fixed using ~/.local even in a --no-site-packages virtualenv
* Distribute #163: scan index links before external links, and don't use the md5 when
comparing two distributions
0.6.12
======
* Distribute #149: Fixed various failures on 2.3/2.4
0.6.11
======
* Found another case of SandboxViolation - fixed
* Distribute #15 and Distribute #48: Introduced a socket timeout of 15 seconds on url openings
* Added indexsidebar.html into MANIFEST.in
* Distribute #108: Fixed TypeError with Python3.1
* Distribute #121: Fixed --help install command trying to actually install.
* Distribute #112: Added an os.makedirs so that Tarek's solution will work.
* Distribute #133: Added --no-find-links to easy_install
* Added easy_install --user
* Distribute #100: Fixed develop --user not taking '.' in PYTHONPATH into account
* Distribute #134: removed spurious UserWarnings. Patch by VanLindberg
* Distribute #138: cant_write_to_target error when setup_requires is used.
* Distribute #147: respect the sys.dont_write_bytecode flag
0.6.10
======
* Reverted change made for the DistributionNotFound exception because
zc.buildout uses the exception message to get the name of the
distribution.
0.6.9
=====
* Distribute #90: unknown setuptools version can be added in the working set
* Distribute #87: setupt.py doesn't try to convert distribute_setup.py anymore
Initial Patch by arfrever.
* Distribute #89: added a side bar with a download link to the doc.
* Distribute #86: fixed missing sentence in pkg_resources doc.
* Added a nicer error message when a DistributionNotFound is raised.
* Distribute #80: test_develop now works with Python 3.1
* Distribute #93: upload_docs now works if there is an empty sub-directory.
* Distribute #70: exec bit on non-exec files
* Distribute #99: now the standalone easy_install command doesn't uses a
"setup.cfg" if any exists in the working directory. It will use it
only if triggered by ``install_requires`` from a setup.py call
(install, develop, etc).
* Distribute #101: Allowing ``os.devnull`` in Sandbox
* Distribute #92: Fixed the "no eggs" found error with MacPort
(platform.mac_ver() fails)
* Distribute #103: test_get_script_header_jython_workaround not run
anymore under py3 with C or POSIX local. Contributed by Arfrever.
* Distribute #104: removed the assertion when the installation fails,
with a nicer message for the end user.
* Distribute #100: making sure there's no SandboxViolation when
the setup script patches setuptools.
0.6.8
=====
* Added "check_packages" in dist. (added in Setuptools 0.6c11)
* Fixed the DONT_PATCH_SETUPTOOLS state.
0.6.7
=====
* Distribute #58: Added --user support to the develop command
* Distribute #11: Generated scripts now wrap their call to the script entry point
in the standard "if name == 'main'"
* Added the 'DONT_PATCH_SETUPTOOLS' environment variable, so virtualenv
can drive an installation that doesn't patch a global setuptools.
* Reviewed unladen-swallow specific change from
http://code.google.com/p/unladen-swallow/source/detail?spec=svn875&r=719
and determined that it no longer applies. Distribute should work fine with
Unladen Swallow 2009Q3.
* Distribute #21: Allow PackageIndex.open_url to gracefully handle all cases of a
httplib.HTTPException instead of just InvalidURL and BadStatusLine.
* Removed virtual-python.py from this distribution and updated documentation
to point to the actively maintained virtualenv instead.
* Distribute #64: use_setuptools no longer rebuilds the distribute egg every
time it is run
* use_setuptools now properly respects the requested version
* use_setuptools will no longer try to import a distribute egg for the
wrong Python version
* Distribute #74: no_fake should be True by default.
* Distribute #72: avoid a bootstrapping issue with easy_install -U
0.6.6
=====
* Unified the bootstrap file so it works on both py2.x and py3k without 2to3
(patch by Holger Krekel)
0.6.5
=====
* Distribute #65: cli.exe and gui.exe are now generated at build time,
depending on the platform in use.
* Distribute #67: Fixed doc typo (PEP 381/PEP 382).
* Distribute no longer shadows setuptools if we require a 0.7-series
setuptools. And an error is raised when installing a 0.7 setuptools with
distribute.
* When run from within buildout, no attempt is made to modify an existing
setuptools egg, whether in a shared egg directory or a system setuptools.
* Fixed a hole in sandboxing allowing builtin file to write outside of
the sandbox.
0.6.4
=====
* Added the generation of ``distribute_setup_3k.py`` during the release.
This closes Distribute #52.
* Added an upload_docs command to easily upload project documentation to
PyPI's https://pythonhosted.org. This close issue Distribute #56.
* Fixed a bootstrap bug on the use_setuptools() API.
0.6.3
=====
setuptools
----------
* Fixed a bunch of calls to file() that caused crashes on Python 3.
bootstrapping
-------------
* Fixed a bug in sorting that caused bootstrap to fail on Python 3.
0.6.2
=====
setuptools
----------
* Added Python 3 support; see docs/python3.txt.
This closes Old Setuptools #39.
* Added option to run 2to3 automatically when installing on Python 3.
This closes issue Distribute #31.
* Fixed invalid usage of requirement.parse, that broke develop -d.
This closes Old Setuptools #44.
* Fixed script launcher for 64-bit Windows.
This closes Old Setuptools #2.
* KeyError when compiling extensions.
This closes Old Setuptools #41.
bootstrapping
-------------
* Fixed bootstrap not working on Windows. This closes issue Distribute #49.
* Fixed 2.6 dependencies. This closes issue Distribute #50.
* Make sure setuptools is patched when running through easy_install
This closes Old Setuptools #40.
0.6.1
=====
setuptools
----------
* package_index.urlopen now catches BadStatusLine and malformed url errors.
This closes Distribute #16 and Distribute #18.
* zip_ok is now False by default. This closes Old Setuptools #33.
* Fixed invalid URL error catching. Old Setuptools #20.
* Fixed invalid bootstraping with easy_install installation (Distribute #40).
Thanks to Florian Schulze for the help.
* Removed buildout/bootstrap.py. A new repository will create a specific
bootstrap.py script.
bootstrapping
-------------
* The bootstrap process leave setuptools alone if detected in the system
and --root or --prefix is provided, but is not in the same location.
This closes Distribute #10.
0.6
===
setuptools
----------
* Packages required at build time where not fully present at install time.
This closes Distribute #12.
* Protected against failures in tarfile extraction. This closes Distribute #10.
* Made Jython api_tests.txt doctest compatible. This closes Distribute #7.
* sandbox.py replaced builtin type file with builtin function open. This
closes Distribute #6.
* Immediately close all file handles. This closes Distribute #3.
* Added compatibility with Subversion 1.6. This references Distribute #1.
pkg_resources
-------------
* Avoid a call to /usr/bin/sw_vers on OSX and use the official platform API
instead. Based on a patch from ronaldoussoren. This closes issue #5.
* Fixed a SandboxViolation for mkdir that could occur in certain cases.
This closes Distribute #13.
* Allow to find_on_path on systems with tight permissions to fail gracefully.
This closes Distribute #9.
* Corrected inconsistency between documentation and code of add_entry.
This closes Distribute #8.
* Immediately close all file handles. This closes Distribute #3.
easy_install
------------
* Immediately close all file handles. This closes Distribute #3.
0.6c9
=====
* Fixed a missing files problem when using Windows source distributions on
non-Windows platforms, due to distutils not handling manifest file line
endings correctly.
* Updated Pyrex support to work with Pyrex 0.9.6 and higher.
* Minor changes for Jython compatibility, including skipping tests that can't
work on Jython.
* Fixed not installing eggs in ``install_requires`` if they were also used for
``setup_requires`` or ``tests_require``.
* Fixed not fetching eggs in ``install_requires`` when running tests.
* Allow ``ez_setup.use_setuptools()`` to upgrade existing setuptools
installations when called from a standalone ``setup.py``.
* Added a warning if a namespace package is declared, but its parent package
is not also declared as a namespace.
* Support Subversion 1.5
* Removed use of deprecated ``md5`` module if ``hashlib`` is available
* Fixed ``bdist_wininst upload`` trying to upload the ``.exe`` twice
* Fixed ``bdist_egg`` putting a ``native_libs.txt`` in the source package's
``.egg-info``, when it should only be in the built egg's ``EGG-INFO``.
* Ensure that _full_name is set on all shared libs before extensions are
checked for shared lib usage. (Fixes a bug in the experimental shared
library build support.)
* Fix to allow unpacked eggs containing native libraries to fail more
gracefully under Google App Engine (with an ``ImportError`` loading the
C-based module, instead of getting a ``NameError``).
* Fixed ``win32.exe`` support for .pth files, so unnecessary directory nesting
is flattened out in the resulting egg. (There was a case-sensitivity
problem that affected some distributions, notably ``pywin32``.)
* Prevent ``--help-commands`` and other junk from showing under Python 2.5
when running ``easy_install --help``.
* Fixed GUI scripts sometimes not executing on Windows
* Fixed not picking up dependency links from recursive dependencies.
* Only make ``.py``, ``.dll`` and ``.so`` files executable when unpacking eggs
* Changes for Jython compatibility
* Improved error message when a requirement is also a directory name, but the
specified directory is not a source package.
* Fixed ``--allow-hosts`` option blocking ``file:`` URLs
* Fixed HTTP SVN detection failing when the page title included a project
name (e.g. on SourceForge-hosted SVN)
* Fix Jython script installation to handle ``#!`` lines better when
``sys.executable`` is a script.
* Removed use of deprecated ``md5`` module if ``hashlib`` is available
* Keep site directories (e.g. ``site-packages``) from being included in
``.pth`` files.
0.6c7
=====
* Fixed ``distutils.filelist.findall()`` crashing on broken symlinks, and
``egg_info`` command failing on new, uncommitted SVN directories.
* Fix import problems with nested namespace packages installed via
``--root`` or ``--single-version-externally-managed``, due to the
parent package not having the child package as an attribute.
* ``ftp:`` download URLs now work correctly.
* The default ``--index-url`` is now ``https://pypi.python.org/simple``, to use
the Python Package Index's new simpler (and faster!) REST API.
0.6c6
=====
* Added ``--egg-path`` option to ``develop`` command, allowing you to force
``.egg-link`` files to use relative paths (allowing them to be shared across
platforms on a networked drive).
* Fix not building binary RPMs correctly.
* Fix "eggsecutables" (such as setuptools' own egg) only being runnable with
bash-compatible shells.
* Fix ``#!`` parsing problems in Windows ``.exe`` script wrappers, when there
was whitespace inside a quoted argument or at the end of the ``#!`` line
(a regression introduced in 0.6c4).
* Fix ``test`` command possibly failing if an older version of the project
being tested was installed on ``sys.path`` ahead of the test source
directory.
* Fix ``find_packages()`` treating ``ez_setup`` and directories with ``.`` in
their names as packages.
* EasyInstall no longer aborts the installation process if a URL it wants to
retrieve can't be downloaded, unless the URL is an actual package download.
Instead, it issues a warning and tries to keep going.
* Fixed distutils-style scripts originally built on Windows having their line
endings doubled when installed on any platform.
* Added ``--local-snapshots-ok`` flag, to allow building eggs from projects
installed using ``setup.py develop``.
* Fixed not HTML-decoding URLs scraped from web pages
0.6c5
=====
* Fix uploaded ``bdist_rpm`` packages being described as ``bdist_egg``
packages under Python versions less than 2.5.
* Fix uploaded ``bdist_wininst`` packages being described as suitable for
"any" version by Python 2.5, even if a ``--target-version`` was specified.
* Fixed ``.dll`` files on Cygwin not having executable permissions when an egg
is installed unzipped.
0.6c4
=====
* Overhauled Windows script wrapping to support ``bdist_wininst`` better.
Scripts installed with ``bdist_wininst`` will always use ``#!python.exe`` or
``#!pythonw.exe`` as the executable name (even when built on non-Windows
platforms!), and the wrappers will look for the executable in the script's
parent directory (which should find the right version of Python).
* Fix ``upload`` command not uploading files built by ``bdist_rpm`` or
``bdist_wininst`` under Python 2.3 and 2.4.
* Add support for "eggsecutable" headers: a ``#!/bin/sh`` script that is
prepended to an ``.egg`` file to allow it to be run as a script on Unix-ish
platforms. (This is mainly so that setuptools itself can have a single-file
installer on Unix, without doing multiple downloads, dealing with firewalls,
etc.)
* Fix problem with empty revision numbers in Subversion 1.4 ``entries`` files
* Use cross-platform relative paths in ``easy-install.pth`` when doing
``develop`` and the source directory is a subdirectory of the installation
target directory.
* Fix a problem installing eggs with a system packaging tool if the project
contained an implicit namespace package; for example if the ``setup()``
listed a namespace package ``foo.bar`` without explicitly listing ``foo``
as a namespace package.
* Added support for HTTP "Basic" authentication using ``http://user:pass@host``
URLs. If a password-protected page contains links to the same host (and
protocol), those links will inherit the credentials used to access the
original page.
* Removed all special support for Sourceforge mirrors, as Sourceforge's
mirror system now works well for non-browser downloads.
* Fixed not recognizing ``win32.exe`` installers that included a custom
bitmap.
* Fixed not allowing ``os.open()`` of paths outside the sandbox, even if they
are opened read-only (e.g. reading ``/dev/urandom`` for random numbers, as
is done by ``os.urandom()`` on some platforms).
* Fixed a problem with ``.pth`` testing on Windows when ``sys.executable``
has a space in it (e.g., the user installed Python to a ``Program Files``
directory).
0.6c3
=====
* Fixed breakages caused by Subversion 1.4's new "working copy" format
* You can once again use "python -m easy_install" with Python 2.4 and above.
* Python 2.5 compatibility fixes added.
0.6c2
=====
* The ``ez_setup`` module displays the conflicting version of setuptools (and
its installation location) when a script requests a version that's not
available.
* Running ``setup.py develop`` on a setuptools-using project will now install
setuptools if needed, instead of only downloading the egg.
* Windows script wrappers now support quoted arguments and arguments
containing spaces. (Patch contributed by Jim Fulton.)
* The ``ez_setup.py`` script now actually works when you put a setuptools
``.egg`` alongside it for bootstrapping an offline machine.
* A writable installation directory on ``sys.path`` is no longer required to
download and extract a source distribution using ``--editable``.
* Generated scripts now use ``-x`` on the ``#!`` line when ``sys.executable``
contains non-ASCII characters, to prevent deprecation warnings about an
unspecified encoding when the script is run.
0.6c1
=====
* Fixed ``AttributeError`` when trying to download a ``setup_requires``
dependency when a distribution lacks a ``dependency_links`` setting.
* Made ``zip-safe`` and ``not-zip-safe`` flag files contain a single byte, so
as to play better with packaging tools that complain about zero-length
files.
* Made ``setup.py develop`` respect the ``--no-deps`` option, which it
previously was ignoring.
* Support ``extra_path`` option to ``setup()`` when ``install`` is run in
backward-compatibility mode.
* Source distributions now always include a ``setup.cfg`` file that explicitly
sets ``egg_info`` options such that they produce an identical version number
to the source distribution's version number. (Previously, the default
version number could be different due to the use of ``--tag-date``, or if
the version was overridden on the command line that built the source
distribution.)
* EasyInstall now includes setuptools version information in the
``User-Agent`` string sent to websites it visits.
0.6b4
=====
* Fix ``register`` not obeying name/version set by ``egg_info`` command, if
``egg_info`` wasn't explicitly run first on the same command line.
* Added ``--no-date`` and ``--no-svn-revision`` options to ``egg_info``
command, to allow suppressing tags configured in ``setup.cfg``.
* Fixed redundant warnings about missing ``README`` file(s); it should now
appear only if you are actually a source distribution.
* Fix creating Python wrappers for non-Python scripts
* Fix ``ftp://`` directory listing URLs from causing a crash when used in the
"Home page" or "Download URL" slots on PyPI.
* Fix ``sys.path_importer_cache`` not being updated when an existing zipfile
or directory is deleted/overwritten.
* Fix not recognizing HTML 404 pages from package indexes.
* Allow ``file://`` URLs to be used as a package index. URLs that refer to
directories will use an internally-generated directory listing if there is
no ``index.html`` file in the directory.
* Allow external links in a package index to be specified using
``rel="homepage"`` or ``rel="download"``, without needing the old
PyPI-specific visible markup.
* Suppressed warning message about possibly-misspelled project name, if an egg
or link for that project name has already been seen.
0.6b3
=====
* Fix ``bdist_egg`` not including files in subdirectories of ``.egg-info``.
* Allow ``.py`` files found by the ``include_package_data`` option to be
automatically included. Remove duplicate data file matches if both
``include_package_data`` and ``package_data`` are used to refer to the same
files.
* Fix local ``--find-links`` eggs not being copied except with
``--always-copy``.
* Fix sometimes not detecting local packages installed outside of "site"
directories.
* Fix mysterious errors during initial ``setuptools`` install, caused by
``ez_setup`` trying to run ``easy_install`` twice, due to a code fallthru
after deleting the egg from which it's running.
0.6b2
=====
* Don't install or update a ``site.py`` patch when installing to a
``PYTHONPATH`` directory with ``--multi-version``, unless an
``easy-install.pth`` file is already in use there.
* Construct ``.pth`` file paths in such a way that installing an egg whose
name begins with ``import`` doesn't cause a syntax error.
* Fixed a bogus warning message that wasn't updated since the 0.5 versions.
0.6b1
=====
* Strip ``module`` from the end of compiled extension modules when computing
the name of a ``.py`` loader/wrapper. (Python's import machinery ignores
this suffix when searching for an extension module.)
* Better ambiguity management: accept ``#egg`` name/version even if processing
what appears to be a correctly-named distutils file, and ignore ``.egg``
files with no ``-``, since valid Python ``.egg`` files always have a version
number (but Scheme eggs often don't).
* Support ``file://`` links to directories in ``--find-links``, so that
easy_install can build packages from local source checkouts.
* Added automatic retry for Sourceforge mirrors. The new download process is
to first just try dl.sourceforge.net, then randomly select mirror IPs and
remove ones that fail, until something works. The removed IPs stay removed
for the remainder of the run.
* Ignore bdist_dumb distributions when looking at download URLs.
0.6a11
======
* Added ``test_loader`` keyword to support custom test loaders
* Added ``setuptools.file_finders`` entry point group to allow implementing
revision control plugins.
* Added ``--identity`` option to ``upload`` command.
* Added ``dependency_links`` to allow specifying URLs for ``--find-links``.
* Enhanced test loader to scan packages as well as modules, and call
``additional_tests()`` if present to get non-unittest tests.
* Support namespace packages in conjunction with system packagers, by omitting
the installation of any ``__init__.py`` files for namespace packages, and
adding a special ``.pth`` file to create a working package in
``sys.modules``.
* Made ``--single-version-externally-managed`` automatic when ``--root`` is
used, so that most system packagers won't require special support for
setuptools.
* Fixed ``setup_requires``, ``tests_require``, etc. not using ``setup.cfg`` or
other configuration files for their option defaults when installing, and
also made the install use ``--multi-version`` mode so that the project
directory doesn't need to support .pth files.
* ``MANIFEST.in`` is now forcibly closed when any errors occur while reading
it. Previously, the file could be left open and the actual error would be
masked by problems trying to remove the open file on Windows systems.
* Process ``dependency_links.txt`` if found in a distribution, by adding the
URLs to the list for scanning.
* Use relative paths in ``.pth`` files when eggs are being installed to the
same directory as the ``.pth`` file. This maximizes portability of the
target directory when building applications that contain eggs.
* Added ``easy_install-N.N`` script(s) for convenience when using multiple
Python versions.
* Added automatic handling of installation conflicts. Eggs are now shifted to
the front of sys.path, in an order consistent with where they came from,
making EasyInstall seamlessly co-operate with system package managers.
The ``--delete-conflicting`` and ``--ignore-conflicts-at-my-risk`` options
are now no longer necessary, and will generate warnings at the end of a
run if you use them.
* Don't recursively traverse subdirectories given to ``--find-links``.
0.6a10
======
* Fixed the ``develop`` command ignoring ``--find-links``.
* Added exhaustive testing of the install directory, including a spawn test
for ``.pth`` file support, and directory writability/existence checks. This
should virtually eliminate the need to set or configure ``--site-dirs``.
* Added ``--prefix`` option for more do-what-I-mean-ishness in the absence of
RTFM-ing. :)
* Enhanced ``PYTHONPATH`` support so that you don't have to put any eggs on it
manually to make it work. ``--multi-version`` is no longer a silent
default; you must explicitly use it if installing to a non-PYTHONPATH,
non-"site" directory.
* Expand ``$variables`` used in the ``--site-dirs``, ``--build-directory``,
``--install-dir``, and ``--script-dir`` options, whether on the command line
or in configuration files.
* Improved SourceForge mirror processing to work faster and be less affected
by transient HTML changes made by SourceForge.
* PyPI searches now use the exact spelling of requirements specified on the
command line or in a project's ``install_requires``. Previously, a
normalized form of the name was used, which could lead to unnecessary
full-index searches when a project's name had an underscore (``_``) in it.
* EasyInstall can now download bare ``.py`` files and wrap them in an egg,
as long as you include an ``#egg=name-version`` suffix on the URL, or if
the ``.py`` file is listed as the "Download URL" on the project's PyPI page.
This allows third parties to "package" trivial Python modules just by
linking to them (e.g. from within their own PyPI page or download links
page).
* The ``--always-copy`` option now skips "system" and "development" eggs since
they can't be reliably copied. Note that this may cause EasyInstall to
choose an older version of a package than what you expected, or it may cause
downloading and installation of a fresh version of what's already installed.
* The ``--find-links`` option previously scanned all supplied URLs and
directories as early as possible, but now only directories and direct
archive links are scanned immediately. URLs are not retrieved unless a
package search was already going to go online due to a package not being
available locally, or due to the use of the ``--update`` or ``-U`` option.
* Fixed the annoying ``--help-commands`` wart.
0.6a9
=====
* The ``sdist`` command no longer uses the traditional ``MANIFEST`` file to
create source distributions. ``MANIFEST.in`` is still read and processed,
as are the standard defaults and pruning. But the manifest is built inside
the project's ``.egg-info`` directory as ``SOURCES.txt``, and it is rebuilt
every time the ``egg_info`` command is run.
* Added the ``include_package_data`` keyword to ``setup()``, allowing you to
automatically include any package data listed in revision control or
``MANIFEST.in``
* Added the ``exclude_package_data`` keyword to ``setup()``, allowing you to
trim back files included via the ``package_data`` and
``include_package_data`` options.
* Fixed ``--tag-svn-revision`` not working when run from a source
distribution.
* Added warning for namespace packages with missing ``declare_namespace()``
* Added ``tests_require`` keyword to ``setup()``, so that e.g. packages
requiring ``nose`` to run unit tests can make this dependency optional
unless the ``test`` command is run.
* Made all commands that use ``easy_install`` respect its configuration
options, as this was causing some problems with ``setup.py install``.
* Added an ``unpack_directory()`` driver to ``setuptools.archive_util``, so
that you can process a directory tree through a processing filter as if it
were a zipfile or tarfile.
* Added an internal ``install_egg_info`` command to use as part of old-style
``install`` operations, that installs an ``.egg-info`` directory with the
package.
* Added a ``--single-version-externally-managed`` option to the ``install``
command so that you can more easily wrap a "flat" egg in a system package.
* Enhanced ``bdist_rpm`` so that it installs single-version eggs that
don't rely on a ``.pth`` file. The ``--no-egg`` option has been removed,
since all RPMs are now built in a more backwards-compatible format.
* Support full roundtrip translation of eggs to and from ``bdist_wininst``
format. Running ``bdist_wininst`` on a setuptools-based package wraps the
egg in an .exe that will safely install it as an egg (i.e., with metadata
and entry-point wrapper scripts), and ``easy_install`` can turn the .exe
back into an ``.egg`` file or directory and install it as such.
* Fixed ``.pth`` file processing picking up nested eggs (i.e. ones inside
"baskets") when they weren't explicitly listed in the ``.pth`` file.
* If more than one URL appears to describe the exact same distribution, prefer
the shortest one. This helps to avoid "table of contents" CGI URLs like the
ones on effbot.org.
* Quote arguments to python.exe (including python's path) to avoid problems
when Python (or a script) is installed in a directory whose name contains
spaces on Windows.
* Support full roundtrip translation of eggs to and from ``bdist_wininst``
format. Running ``bdist_wininst`` on a setuptools-based package wraps the
egg in an .exe that will safely install it as an egg (i.e., with metadata
and entry-point wrapper scripts), and ``easy_install`` can turn the .exe
back into an ``.egg`` file or directory and install it as such.
0.6a8
=====
* Fixed some problems building extensions when Pyrex was installed, especially
with Python 2.4 and/or packages using SWIG.
* Made ``develop`` command accept all the same options as ``easy_install``,
and use the ``easy_install`` command's configuration settings as defaults.
* Made ``egg_info --tag-svn-revision`` fall back to extracting the revision
number from ``PKG-INFO`` in case it is being run on a source distribution of
a snapshot taken from a Subversion-based project.
* Automatically detect ``.dll``, ``.so`` and ``.dylib`` files that are being
installed as data, adding them to ``native_libs.txt`` automatically.
* Fixed some problems with fresh checkouts of projects that don't include
``.egg-info/PKG-INFO`` under revision control and put the project's source
code directly in the project directory. If such a package had any
requirements that get processed before the ``egg_info`` command can be run,
the setup scripts would fail with a "Missing 'Version:' header and/or
PKG-INFO file" error, because the egg runtime interpreted the unbuilt
metadata in a directory on ``sys.path`` (i.e. the current directory) as
being a corrupted egg. Setuptools now monkeypatches the distribution
metadata cache to pretend that the egg has valid version information, until
it has a chance to make it actually be so (via the ``egg_info`` command).
* Update for changed SourceForge mirror format
* Fixed not installing dependencies for some packages fetched via Subversion
* Fixed dependency installation with ``--always-copy`` not using the same
dependency resolution procedure as other operations.
* Fixed not fully removing temporary directories on Windows, if a Subversion
checkout left read-only files behind
* Fixed some problems building extensions when Pyrex was installed, especially
with Python 2.4 and/or packages using SWIG.
0.6a7
=====
* Fixed not being able to install Windows script wrappers using Python 2.3
0.6a6
=====
* Added support for "traditional" PYTHONPATH-based non-root installation, and
also the convenient ``virtual-python.py`` script, based on a contribution
by Ian Bicking. The setuptools egg now contains a hacked ``site`` module
that makes the PYTHONPATH-based approach work with .pth files, so that you
can get the full EasyInstall feature set on such installations.
* Added ``--no-deps`` and ``--allow-hosts`` options.
* Improved Windows ``.exe`` script wrappers so that the script can have the
same name as a module without confusing Python.
* Changed dependency processing so that it's breadth-first, allowing a
depender's preferences to override those of a dependee, to prevent conflicts
when a lower version is acceptable to the dependee, but not the depender.
Also, ensure that currently installed/selected packages aren't given
precedence over ones desired by a package being installed, which could
cause conflict errors.
0.6a5
=====
* Fixed missing gui/cli .exe files in distribution. Fixed bugs in tests.
0.6a3
=====
* Added ``gui_scripts`` entry point group to allow installing GUI scripts
on Windows and other platforms. (The special handling is only for Windows;
other platforms are treated the same as for ``console_scripts``.)
* Improved error message when trying to use old ways of running
``easy_install``. Removed the ability to run via ``python -m`` or by
running ``easy_install.py``; ``easy_install`` is the command to run on all
supported platforms.
* Improved wrapper script generation and runtime initialization so that a
VersionConflict doesn't occur if you later install a competing version of a
needed package as the default version of that package.
* Fixed a problem parsing version numbers in ``#egg=`` links.
0.6a2
=====
* Added ``console_scripts`` entry point group to allow installing scripts
without the need to create separate script files. On Windows, console
scripts get an ``.exe`` wrapper so you can just type their name. On other
platforms, the scripts are written without a file extension.
* EasyInstall can now install "console_scripts" defined by packages that use
``setuptools`` and define appropriate entry points. On Windows, console
scripts get an ``.exe`` wrapper so you can just type their name. On other
platforms, the scripts are installed without a file extension.
* Using ``python -m easy_install`` or running ``easy_install.py`` is now
DEPRECATED, since an ``easy_install`` wrapper is now available on all
platforms.
0.6a1
=====
* Added support for building "old-style" RPMs that don't install an egg for
the target package, using a ``--no-egg`` option.
* The ``build_ext`` command now works better when using the ``--inplace``
option and multiple Python versions. It now makes sure that all extensions
match the current Python version, even if newer copies were built for a
different Python version.
* The ``upload`` command no longer attaches an extra ``.zip`` when uploading
eggs, as PyPI now supports egg uploads without trickery.
* The ``ez_setup`` script/module now displays a warning before downloading
the setuptools egg, and attempts to check the downloaded egg against an
internal MD5 checksum table.
* Fixed the ``--tag-svn-revision`` option of ``egg_info`` not finding the
latest revision number; it was using the revision number of the directory
containing ``setup.py``, not the highest revision number in the project.
* Added ``eager_resources`` setup argument
* The ``sdist`` command now recognizes Subversion "deleted file" entries and
does not include them in source distributions.
* ``setuptools`` now embeds itself more thoroughly into the distutils, so that
other distutils extensions (e.g. py2exe, py2app) will subclass setuptools'
versions of things, rather than the native distutils ones.
* Added ``entry_points`` and ``setup_requires`` arguments to ``setup()``;
``setup_requires`` allows you to automatically find and download packages
that are needed in order to *build* your project (as opposed to running it).
* ``setuptools`` now finds its commands, ``setup()`` argument validators, and
metadata writers using entry points, so that they can be extended by
third-party packages. See `Creating distutils Extensions
`_
for more details.
* The vestigial ``depends`` command has been removed. It was never finished
or documented, and never would have worked without EasyInstall - which it
pre-dated and was never compatible with.
* EasyInstall now does MD5 validation of downloads from PyPI, or from any link
that has an "#md5=..." trailer with a 32-digit lowercase hex md5 digest.
* EasyInstall now handles symlinks in target directories by removing the link,
rather than attempting to overwrite the link's destination. This makes it
easier to set up an alternate Python "home" directory (as described in
the Non-Root Installation section of the docs).
* Added support for handling MacOS platform information in ``.egg`` filenames,
based on a contribution by Kevin Dangoor. You may wish to delete and
reinstall any eggs whose filename includes "darwin" and "Power_Macintosh",
because the format for this platform information has changed so that minor
OS X upgrades (such as 10.4.1 to 10.4.2) do not cause eggs built with a
previous OS version to become obsolete.
* easy_install's dependency processing algorithms have changed. When using
``--always-copy``, it now ensures that dependencies are copied too. When
not using ``--always-copy``, it tries to use a single resolution loop,
rather than recursing.
* Fixed installing extra ``.pyc`` or ``.pyo`` files for scripts with ``.py``
extensions.
* Added ``--site-dirs`` option to allow adding custom "site" directories.
Made ``easy-install.pth`` work in platform-specific alternate site
directories (e.g. ``~/Library/Python/2.x/site-packages`` on Mac OS X).
* If you manually delete the current version of a package, the next run of
EasyInstall against the target directory will now remove the stray entry
from the ``easy-install.pth`` file.
* EasyInstall now recognizes URLs with a ``#egg=project_name`` fragment ID
as pointing to the named project's source checkout. Such URLs have a lower
match precedence than any other kind of distribution, so they'll only be
used if they have a higher version number than any other available
distribution, or if you use the ``--editable`` option. The ``#egg``
fragment can contain a version if it's formatted as ``#egg=proj-ver``,
where ``proj`` is the project name, and ``ver`` is the version number. You
*must* use the format for these values that the ``bdist_egg`` command uses;
i.e., all non-alphanumeric runs must be condensed to single underscore
characters.
* Added the ``--editable`` option; see Editing and Viewing Source Packages
in the docs. Also, slightly changed the behavior of the
``--build-directory`` option.
* Fixed the setup script sandbox facility not recognizing certain paths as
valid on case-insensitive platforms.
0.5a12
======
* The zip-safety scanner now checks for modules that might be used with
``python -m``, and marks them as unsafe for zipping, since Python 2.4 can't
handle ``-m`` on zipped modules.
* Fix ``python -m easy_install`` not working due to setuptools being installed
as a zipfile. Update safety scanner to check for modules that might be used
as ``python -m`` scripts.
* Misc. fixes for win32.exe support, including changes to support Python 2.4's
changed ``bdist_wininst`` format.
0.5a11
======
* Fix breakage of the "develop" command that was caused by the addition of
``--always-unzip`` to the ``easy_install`` command.
0.5a10
======
* Put the ``easy_install`` module back in as a module, as it's needed for
``python -m`` to run it!
* Allow ``--find-links/-f`` to accept local directories or filenames as well
as URLs.
0.5a9
=====
* Include ``svn:externals`` directories in source distributions as well as
normal subversion-controlled files and directories.
* Added ``exclude=patternlist`` option to ``setuptools.find_packages()``
* Changed --tag-svn-revision to include an "r" in front of the revision number
for better readability.
* Added ability to build eggs without including source files (except for any
scripts, of course), using the ``--exclude-source-files`` option to
``bdist_egg``.
* ``setup.py install`` now automatically detects when an "unmanaged" package
or module is going to be on ``sys.path`` ahead of a package being installed,
thereby preventing the newer version from being imported. If this occurs,
a warning message is output to ``sys.stderr``, but installation proceeds
anyway. The warning message informs the user what files or directories
need deleting, and advises them they can also use EasyInstall (with the
``--delete-conflicting`` option) to do it automatically.
* The ``egg_info`` command now adds a ``top_level.txt`` file to the metadata
directory that lists all top-level modules and packages in the distribution.
This is used by the ``easy_install`` command to find possibly-conflicting
"unmanaged" packages when installing the distribution.
* Added ``zip_safe`` and ``namespace_packages`` arguments to ``setup()``.
Added package analysis to determine zip-safety if the ``zip_safe`` flag
is not given, and advise the author regarding what code might need changing.
* Fixed the swapped ``-d`` and ``-b`` options of ``bdist_egg``.
* EasyInstall now automatically detects when an "unmanaged" package or
module is going to be on ``sys.path`` ahead of a package you're installing,
thereby preventing the newer version from being imported. By default, it
will abort installation to alert you of the problem, but there are also
new options (``--delete-conflicting`` and ``--ignore-conflicts-at-my-risk``)
available to change the default behavior. (Note: this new feature doesn't
take effect for egg files that were built with older ``setuptools``
versions, because they lack the new metadata file required to implement it.)
* The ``easy_install`` distutils command now uses ``DistutilsError`` as its
base error type for errors that should just issue a message to stderr and
exit the program without a traceback.
* EasyInstall can now be given a path to a directory containing a setup
script, and it will attempt to build and install the package there.
* EasyInstall now performs a safety analysis on module contents to determine
whether a package is likely to run in zipped form, and displays
information about what modules may be doing introspection that would break
when running as a zipfile.
* Added the ``--always-unzip/-Z`` option, to force unzipping of packages that
would ordinarily be considered safe to unzip, and changed the meaning of
``--zip-ok/-z`` to "always leave everything zipped".
0.5a8
=====
* The "egg_info" command now always sets the distribution metadata to "safe"
forms of the distribution name and version, so that distribution files will
be generated with parseable names (i.e., ones that don't include '-' in the
name or version). Also, this means that if you use the various ``--tag``
options of "egg_info", any distributions generated will use the tags in the
version, not just egg distributions.
* Added support for defining command aliases in distutils configuration files,
under the "[aliases]" section. To prevent recursion and to allow aliases to
call the command of the same name, a given alias can be expanded only once
per command-line invocation. You can define new aliases with the "alias"
command, either for the local, global, or per-user configuration.
* Added "rotate" command to delete old distribution files, given a set of
patterns to match and the number of files to keep. (Keeps the most
recently-modified distribution files matching each pattern.)
* Added "saveopts" command that saves all command-line options for the current
invocation to the local, global, or per-user configuration file. Useful for
setting defaults without having to hand-edit a configuration file.
* Added a "setopt" command that sets a single option in a specified distutils
configuration file.
* There is now a separate documentation page for setuptools; revision
history that's not specific to EasyInstall has been moved to that page.
0.5a7
=====
* Added "upload" support for egg and source distributions, including a bug
fix for "upload" and a temporary workaround for lack of .egg support in
PyPI.
0.5a6
=====
* Beefed up the "sdist" command so that if you don't have a MANIFEST.in, it
will include all files under revision control (CVS or Subversion) in the
current directory, and it will regenerate the list every time you create a
source distribution, not just when you tell it to. This should make the
default "do what you mean" more often than the distutils' default behavior
did, while still retaining the old behavior in the presence of MANIFEST.in.
* Fixed the "develop" command always updating .pth files, even if you
specified ``-n`` or ``--dry-run``.
* Slightly changed the format of the generated version when you use
``--tag-build`` on the "egg_info" command, so that you can make tagged
revisions compare *lower* than the version specified in setup.py (e.g. by
using ``--tag-build=dev``).
0.5a5
=====
* Added ``develop`` command to ``setuptools``-based packages. This command
installs an ``.egg-link`` pointing to the package's source directory, and
script wrappers that ``execfile()`` the source versions of the package's
scripts. This lets you put your development checkout(s) on sys.path without
having to actually install them. (To uninstall the link, use
use ``setup.py develop --uninstall``.)
* Added ``egg_info`` command to ``setuptools``-based packages. This command
just creates or updates the "projectname.egg-info" directory, without
building an egg. (It's used by the ``bdist_egg``, ``test``, and ``develop``
commands.)
* Enhanced the ``test`` command so that it doesn't install the package, but
instead builds any C extensions in-place, updates the ``.egg-info``
metadata, adds the source directory to ``sys.path``, and runs the tests
directly on the source. This avoids an "unmanaged" installation of the
package to ``site-packages`` or elsewhere.
* Made ``easy_install`` a standard ``setuptools`` command, moving it from
the ``easy_install`` module to ``setuptools.command.easy_install``. Note
that if you were importing or extending it, you must now change your imports
accordingly. ``easy_install.py`` is still installed as a script, but not as
a module.
0.5a4
=====
* Setup scripts using setuptools can now list their dependencies directly in
the setup.py file, without having to manually create a ``depends.txt`` file.
The ``install_requires`` and ``extras_require`` arguments to ``setup()``
are used to create a dependencies file automatically. If you are manually
creating ``depends.txt`` right now, please switch to using these setup
arguments as soon as practical, because ``depends.txt`` support will be
removed in the 0.6 release cycle. For documentation on the new arguments,
see the ``setuptools.dist.Distribution`` class.
* Setup scripts using setuptools now always install using ``easy_install``
internally, for ease of uninstallation and upgrading.
* Added ``--always-copy/-a`` option to always copy needed packages to the
installation directory, even if they're already present elsewhere on
sys.path. (In previous versions, this was the default behavior, but now
you must request it.)
* Added ``--upgrade/-U`` option to force checking PyPI for latest available
version(s) of all packages requested by name and version, even if a matching
version is available locally.
* Added automatic installation of dependencies declared by a distribution
being installed. These dependencies must be listed in the distribution's
``EGG-INFO`` directory, so the distribution has to have declared its
dependencies by using setuptools. If a package has requirements it didn't
declare, you'll still have to deal with them yourself. (E.g., by asking
EasyInstall to find and install them.)
* Added the ``--record`` option to ``easy_install`` for the benefit of tools
that run ``setup.py install --record=filename`` on behalf of another
packaging system.)
0.5a3
=====
* Fixed not setting script permissions to allow execution.
* Improved sandboxing so that setup scripts that want a temporary directory
(e.g. pychecker) can still run in the sandbox.
0.5a2
=====
* Fix stupid stupid refactoring-at-the-last-minute typos. :(
0.5a1
=====
* Added support for "self-installation" bootstrapping. Packages can now
include ``ez_setup.py`` in their source distribution, and add the following
to their ``setup.py``, in order to automatically bootstrap installation of
setuptools as part of their setup process::
from ez_setup import use_setuptools
use_setuptools()
from setuptools import setup
# etc...
* Added support for converting ``.win32.exe`` installers to eggs on the fly.
EasyInstall will now recognize such files by name and install them.
* Fixed a problem with picking the "best" version to install (versions were
being sorted as strings, rather than as parsed values)
0.4a4
=====
* Added support for the distutils "verbose/quiet" and "dry-run" options, as
well as the "optimize" flag.
* Support downloading packages that were uploaded to PyPI (by scanning all
links on package pages, not just the homepage/download links).
0.4a3
=====
* Add progress messages to the search/download process so that you can tell
what URLs it's reading to find download links. (Hopefully, this will help
people report out-of-date and broken links to package authors, and to tell
when they've asked for a package that doesn't exist.)
0.4a2
=====
* Added ``ez_setup.py`` installer/bootstrap script to make initial setuptools
installation easier, and to allow distributions using setuptools to avoid
having to include setuptools in their source distribution.
* All downloads are now managed by the ``PackageIndex`` class (which is now
subclassable and replaceable), so that embedders can more easily override
download logic, give download progress reports, etc. The class has also
been moved to the new ``setuptools.package_index`` module.
* The ``Installer`` class no longer handles downloading, manages a temporary
directory, or tracks the ``zip_ok`` option. Downloading is now handled
by ``PackageIndex``, and ``Installer`` has become an ``easy_install``
command class based on ``setuptools.Command``.
* There is a new ``setuptools.sandbox.run_setup()`` API to invoke a setup
script in a directory sandbox, and a new ``setuptools.archive_util`` module
with an ``unpack_archive()`` API. These were split out of EasyInstall to
allow reuse by other tools and applications.
* ``setuptools.Command`` now supports reinitializing commands using keyword
arguments to set/reset options. Also, ``Command`` subclasses can now set
their ``command_consumes_arguments`` attribute to ``True`` in order to
receive an ``args`` option containing the rest of the command line.
* Added support for installing scripts
* Added support for setting options via distutils configuration files, and
using distutils' default options as a basis for EasyInstall's defaults.
* Renamed ``--scan-url/-s`` to ``--find-links/-f`` to free up ``-s`` for the
script installation directory option.
* Use ``urllib2`` instead of ``urllib``, to allow use of ``https:`` URLs if
Python includes SSL support.
0.4a1
=====
* Added ``--scan-url`` and ``--index-url`` options, to scan download pages
and search PyPI for needed packages.
0.3a4
=====
* Restrict ``--build-directory=DIR/-b DIR`` option to only be used with single
URL installs, to avoid running the wrong setup.py.
0.3a3
=====
* Added ``--build-directory=DIR/-b DIR`` option.
* Added "installation report" that explains how to use 'require()' when doing
a multiversion install or alternate installation directory.
* Added SourceForge mirror auto-select (Contributed by Ian Bicking)
* Added "sandboxing" that stops a setup script from running if it attempts to
write to the filesystem outside of the build area
* Added more workarounds for packages with quirky ``install_data`` hacks
0.3a2
=====
* Added new options to ``bdist_egg`` to allow tagging the egg's version number
with a subversion revision number, the current date, or an explicit tag
value. Run ``setup.py bdist_egg --help`` to get more information.
* Added subversion download support for ``svn:`` and ``svn+`` URLs, as well as
automatic recognition of HTTP subversion URLs (Contributed by Ian Bicking)
* Misc. bug fixes
0.3a1
=====
* Initial release.
././@PaxHeader 0000000 0000000 0000000 00000000034 00000000000 010212 x ustar 00 28 mtime=1692360483.5595517
setuptools-68.1.2/PKG-INFO 0000644 0001751 0000173 00000006736 14467657444 014570 0 ustar 00runner docker Metadata-Version: 2.1
Name: setuptools
Version: 68.1.2
Summary: Easily download, build, install, upgrade, and uninstall Python packages
Home-page: https://github.com/pypa/setuptools
Author: Python Packaging Authority
Author-email: distutils-sig@python.org
Project-URL: Documentation, https://setuptools.pypa.io/
Project-URL: Changelog, https://setuptools.pypa.io/en/stable/history.html
Keywords: CPAN PyPI distutils eggs package management
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: MIT License
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Classifier: Topic :: System :: Archiving :: Packaging
Classifier: Topic :: System :: Systems Administration
Classifier: Topic :: Utilities
Requires-Python: >=3.8
Provides-Extra: testing
Provides-Extra: testing-integration
Provides-Extra: docs
Provides-Extra: ssl
Provides-Extra: certs
License-File: LICENSE
.. image:: https://img.shields.io/pypi/v/setuptools.svg
:target: https://pypi.org/project/setuptools
.. image:: https://img.shields.io/pypi/pyversions/setuptools.svg
.. image:: https://github.com/pypa/setuptools/workflows/tests/badge.svg
:target: https://github.com/pypa/setuptools/actions?query=workflow%3A%22tests%22
:alt: tests
.. image:: https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/charliermarsh/ruff/main/assets/badge/v2.json
:target: https://github.com/astral-sh/ruff
:alt: Ruff
.. image:: https://img.shields.io/badge/code%20style-black-000000.svg
:target: https://github.com/psf/black
:alt: Code style: Black
.. image:: https://img.shields.io/readthedocs/setuptools/latest.svg
:target: https://setuptools.pypa.io
.. image:: https://img.shields.io/badge/skeleton-2023-informational
:target: https://blog.jaraco.com/skeleton
.. image:: https://img.shields.io/codecov/c/github/pypa/setuptools/master.svg?logo=codecov&logoColor=white
:target: https://codecov.io/gh/pypa/setuptools
.. image:: https://tidelift.com/badges/github/pypa/setuptools?style=flat
:target: https://tidelift.com/subscription/pkg/pypi-setuptools?utm_source=pypi-setuptools&utm_medium=readme
.. image:: https://img.shields.io/discord/803025117553754132
:target: https://discord.com/channels/803025117553754132/815945031150993468
:alt: Discord
See the `Installation Instructions
`_ in the Python Packaging
User's Guide for instructions on installing, upgrading, and uninstalling
Setuptools.
Questions and comments should be directed to `GitHub Discussions
`_.
Bug reports and especially tested patches may be
submitted directly to the `bug tracker
`_.
Code of Conduct
===============
Everyone interacting in the setuptools project's codebases, issue trackers,
chat rooms, and fora is expected to follow the
`PSF Code of Conduct `_.
For Enterprise
==============
Available as part of the Tidelift Subscription.
Setuptools and the maintainers of thousands of other packages are working with Tidelift to deliver one enterprise subscription that covers all of the open source you use.
`Learn more `_.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/README.rst 0000644 0001751 0000173 00000004652 14467657412 015150 0 ustar 00runner docker .. image:: https://img.shields.io/pypi/v/setuptools.svg
:target: https://pypi.org/project/setuptools
.. image:: https://img.shields.io/pypi/pyversions/setuptools.svg
.. image:: https://github.com/pypa/setuptools/workflows/tests/badge.svg
:target: https://github.com/pypa/setuptools/actions?query=workflow%3A%22tests%22
:alt: tests
.. image:: https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/charliermarsh/ruff/main/assets/badge/v2.json
:target: https://github.com/astral-sh/ruff
:alt: Ruff
.. image:: https://img.shields.io/badge/code%20style-black-000000.svg
:target: https://github.com/psf/black
:alt: Code style: Black
.. image:: https://img.shields.io/readthedocs/setuptools/latest.svg
:target: https://setuptools.pypa.io
.. image:: https://img.shields.io/badge/skeleton-2023-informational
:target: https://blog.jaraco.com/skeleton
.. image:: https://img.shields.io/codecov/c/github/pypa/setuptools/master.svg?logo=codecov&logoColor=white
:target: https://codecov.io/gh/pypa/setuptools
.. image:: https://tidelift.com/badges/github/pypa/setuptools?style=flat
:target: https://tidelift.com/subscription/pkg/pypi-setuptools?utm_source=pypi-setuptools&utm_medium=readme
.. image:: https://img.shields.io/discord/803025117553754132
:target: https://discord.com/channels/803025117553754132/815945031150993468
:alt: Discord
See the `Installation Instructions
`_ in the Python Packaging
User's Guide for instructions on installing, upgrading, and uninstalling
Setuptools.
Questions and comments should be directed to `GitHub Discussions
`_.
Bug reports and especially tested patches may be
submitted directly to the `bug tracker
`_.
Code of Conduct
===============
Everyone interacting in the setuptools project's codebases, issue trackers,
chat rooms, and fora is expected to follow the
`PSF Code of Conduct `_.
For Enterprise
==============
Available as part of the Tidelift Subscription.
Setuptools and the maintainers of thousands of other packages are working with Tidelift to deliver one enterprise subscription that covers all of the open source you use.
`Learn more `_.
././@PaxHeader 0000000 0000000 0000000 00000000034 00000000000 010212 x ustar 00 28 mtime=1692360483.4835474
setuptools-68.1.2/_distutils_hack/ 0000755 0001751 0000173 00000000000 14467657443 016627 5 ustar 00runner docker ././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/_distutils_hack/__init__.py 0000644 0001751 0000173 00000014233 14467657412 020737 0 ustar 00runner docker # don't import any costly modules
import sys
import os
is_pypy = '__pypy__' in sys.builtin_module_names
def warn_distutils_present():
if 'distutils' not in sys.modules:
return
if is_pypy and sys.version_info < (3, 7):
# PyPy for 3.6 unconditionally imports distutils, so bypass the warning
# https://foss.heptapod.net/pypy/pypy/-/blob/be829135bc0d758997b3566062999ee8b23872b4/lib-python/3/site.py#L250
return
import warnings
warnings.warn(
"Distutils was imported before Setuptools, but importing Setuptools "
"also replaces the `distutils` module in `sys.modules`. This may lead "
"to undesirable behaviors or errors. To avoid these issues, avoid "
"using distutils directly, ensure that setuptools is installed in the "
"traditional way (e.g. not an editable install), and/or make sure "
"that setuptools is always imported before distutils."
)
def clear_distutils():
if 'distutils' not in sys.modules:
return
import warnings
warnings.warn("Setuptools is replacing distutils.")
mods = [
name
for name in sys.modules
if name == "distutils" or name.startswith("distutils.")
]
for name in mods:
del sys.modules[name]
def enabled():
"""
Allow selection of distutils by environment variable.
"""
which = os.environ.get('SETUPTOOLS_USE_DISTUTILS', 'local')
return which == 'local'
def ensure_local_distutils():
import importlib
clear_distutils()
# With the DistutilsMetaFinder in place,
# perform an import to cause distutils to be
# loaded from setuptools._distutils. Ref #2906.
with shim():
importlib.import_module('distutils')
# check that submodules load as expected
core = importlib.import_module('distutils.core')
assert '_distutils' in core.__file__, core.__file__
assert 'setuptools._distutils.log' not in sys.modules
def do_override():
"""
Ensure that the local copy of distutils is preferred over stdlib.
See https://github.com/pypa/setuptools/issues/417#issuecomment-392298401
for more motivation.
"""
if enabled():
warn_distutils_present()
ensure_local_distutils()
class _TrivialRe:
def __init__(self, *patterns):
self._patterns = patterns
def match(self, string):
return all(pat in string for pat in self._patterns)
class DistutilsMetaFinder:
def find_spec(self, fullname, path, target=None):
# optimization: only consider top level modules and those
# found in the CPython test suite.
if path is not None and not fullname.startswith('test.'):
return
method_name = 'spec_for_{fullname}'.format(**locals())
method = getattr(self, method_name, lambda: None)
return method()
def spec_for_distutils(self):
if self.is_cpython():
return
import importlib
import importlib.abc
import importlib.util
try:
mod = importlib.import_module('setuptools._distutils')
except Exception:
# There are a couple of cases where setuptools._distutils
# may not be present:
# - An older Setuptools without a local distutils is
# taking precedence. Ref #2957.
# - Path manipulation during sitecustomize removes
# setuptools from the path but only after the hook
# has been loaded. Ref #2980.
# In either case, fall back to stdlib behavior.
return
class DistutilsLoader(importlib.abc.Loader):
def create_module(self, spec):
mod.__name__ = 'distutils'
return mod
def exec_module(self, module):
pass
return importlib.util.spec_from_loader(
'distutils', DistutilsLoader(), origin=mod.__file__
)
@staticmethod
def is_cpython():
"""
Suppress supplying distutils for CPython (build and tests).
Ref #2965 and #3007.
"""
return os.path.isfile('pybuilddir.txt')
def spec_for_pip(self):
"""
Ensure stdlib distutils when running under pip.
See pypa/pip#8761 for rationale.
"""
if sys.version_info >= (3, 12) or self.pip_imported_during_build():
return
clear_distutils()
self.spec_for_distutils = lambda: None
@classmethod
def pip_imported_during_build(cls):
"""
Detect if pip is being imported in a build script. Ref #2355.
"""
import traceback
return any(
cls.frame_file_is_setup(frame) for frame, line in traceback.walk_stack(None)
)
@staticmethod
def frame_file_is_setup(frame):
"""
Return True if the indicated frame suggests a setup.py file.
"""
# some frames may not have __file__ (#2940)
return frame.f_globals.get('__file__', '').endswith('setup.py')
def spec_for_sensitive_tests(self):
"""
Ensure stdlib distutils when running select tests under CPython.
python/cpython#91169
"""
clear_distutils()
self.spec_for_distutils = lambda: None
sensitive_tests = (
[
'test.test_distutils',
'test.test_peg_generator',
'test.test_importlib',
]
if sys.version_info < (3, 10)
else [
'test.test_distutils',
]
)
for name in DistutilsMetaFinder.sensitive_tests:
setattr(
DistutilsMetaFinder,
f'spec_for_{name}',
DistutilsMetaFinder.spec_for_sensitive_tests,
)
DISTUTILS_FINDER = DistutilsMetaFinder()
def add_shim():
DISTUTILS_FINDER in sys.meta_path or insert_shim()
class shim:
def __enter__(self):
insert_shim()
def __exit__(self, exc, value, tb):
_remove_shim()
def insert_shim():
sys.meta_path.insert(0, DISTUTILS_FINDER)
def _remove_shim():
try:
sys.meta_path.remove(DISTUTILS_FINDER)
except ValueError:
pass
if sys.version_info < (3, 12):
# DistutilsMetaFinder can only be disabled in Python < 3.12 (PEP 632)
remove_shim = _remove_shim
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/_distutils_hack/override.py 0000644 0001751 0000173 00000000054 14467657412 021013 0 ustar 00runner docker __import__('_distutils_hack').do_override()
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/conftest.py 0000644 0001751 0000173 00000003126 14467657412 015653 0 ustar 00runner docker import sys
import pytest
pytest_plugins = 'setuptools.tests.fixtures'
def pytest_addoption(parser):
parser.addoption(
"--package_name",
action="append",
default=[],
help="list of package_name to pass to test functions",
)
parser.addoption(
"--integration",
action="store_true",
default=False,
help="run integration tests (only)",
)
def pytest_configure(config):
config.addinivalue_line("markers", "integration: integration tests")
config.addinivalue_line("markers", "uses_network: tests may try to download files")
collect_ignore = [
'tests/manual_test.py',
'setuptools/tests/mod_with_constant.py',
'setuptools/_distutils',
'_distutils_hack',
'setuptools/extern',
'pkg_resources/extern',
'pkg_resources/tests/data',
'setuptools/_vendor',
'pkg_resources/_vendor',
'setuptools/config/_validate_pyproject',
]
if sys.version_info < (3, 6):
collect_ignore.append('docs/conf.py') # uses f-strings
collect_ignore.append('pavement.py')
if sys.version_info < (3, 9) or sys.platform == 'cygwin':
collect_ignore.append('tools/finalize.py')
@pytest.fixture(autouse=True)
def _skip_integration(request):
running_integration_tests = request.config.getoption("--integration")
is_integration_test = request.node.get_closest_marker("integration")
if running_integration_tests and not is_integration_test:
pytest.skip("running integration tests only")
if not running_integration_tests and is_integration_test:
pytest.skip("skipping integration tests")
././@PaxHeader 0000000 0000000 0000000 00000000034 00000000000 010212 x ustar 00 28 mtime=1692360483.4835474
setuptools-68.1.2/docs/ 0000755 0001751 0000173 00000000000 14467657443 014406 5 ustar 00runner docker ././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/artwork.rst 0000644 0001751 0000173 00000011103 14467657412 016621 0 ustar 00runner docker =======
Artwork
=======
.. figure:: images/logo-over-white.svg
:align: center
Setuptools logo, designed in 2021 by `Anderson Bravalheri`_
Elements of Design
==================
The main colours of the design are a dark pastel azure (``#336790``) and a pale
orange (``#E5B62F``), referred in this document simply as "blue" and "yellow"
respectively. The text uses the *Monoid* typeface, an open source webfont that
was developed by Andreas Larsen and contributors in 2015 and is distributed
under the MIT or SIL licenses (more information at
https://github.com/larsenwork/monoid)
Usage
=====
The preferred way of using the setuptools logo is over a white (or light)
background. Alternatively, the following options can be considered, depending
on the circumstances:
- *"negative"* design - for dark backgrounds (e.g. website displayed in "dark
mode"): the white colour (``#FFFFFF``) of the background and the "blue"
(``#336790``) colour of the design can be swapped.
- *"monochrome"* - when colours are not available (e.g. black and white printed
media): a completely black or white version of the logo can also be used.
- *"banner"* mode: the symbol and text can be used alongside depending on the
available space.
The following image illustrate these alternatives:
.. image:: images/logo-demo.svg
:align: center
Please refer to the SVG files in the `setuptools repository`_ for the specific
shapes and proportions between the elements of the design.
Working with the Design
=======================
The `setuptools repository`_ contains a series of vector representations of the
design under the ``docs/images`` directory. These representations can be
manipulated via any graphic editor that support SVG files,
however the free and open-source software Inkscape_ is recommended for maximum
compatibility.
When selecting the right file to work with, file names including
``editable-inkscape`` indicate "more editable" elements (e.g. editable text),
while the others prioritise SVG paths for maximum reproducibility.
Also notice that you might have to `install the correct fonts`_ to be able to
visualise or edit some of the designs.
Inspiration
===========
This design was inspired by :user:`cajhne`'s `original proposal`_ and the
ancient symbol of the ouroboros_.
It features a snake moving in a circular trajectory not only as a reference to
the Python programming language but also to the :pep:`wheel package format <427>` as one
of the distribution formats supported by setuptools.
The shape of the snake also resembles a cog, which together with the hammer is
a nod to the two words that compose the name of the project.
License
=======
This logo, design variations or a modified version may be used by anyone to
refer to setuptools, but does not indicate endorsement by the project.
Redistribution, usage and derivative works are permitted under the same license
used by the setuptools software (MIT):
.. code-block:: text
Copyright (c) Anderson Bravalheri
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.
THE USAGE OF THIS LOGO AND ARTWORK DOES NOT INDICATE ENDORSEMENT BY THE
SETUPTOOLS PROJECT.
Whenever possible, please make the image a link to
https://github.com/pypa/setuptools or https://setuptools.pypa.io.
.. _Anderson Bravalheri: https://github.com/abravalheri
.. _Inkscape: https://inkscape.org
.. _setuptools repository: https://github.com/pypa/setuptools
.. _install the correct fonts: https://wiki.inkscape.org/wiki/Installing_fonts
.. _original proposal: https://github.com/pypa/setuptools/issues/2227#issuecomment-653628344
.. _ouroboros: https://en.wikipedia.org/wiki/Ouroboros
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/build_meta.rst 0000644 0001751 0000173 00000015422 14467657412 017245 0 ustar 00runner docker =======================================
Build System Support
=======================================
What is it?
-------------
Python packaging has come `a long way `_.
The traditional ``setuptools`` way of packaging Python modules
uses a ``setup()`` function within the ``setup.py`` script. Commands such as
``python setup.py bdist`` or ``python setup.py bdist_wheel`` generate a
distribution bundle and ``python setup.py install`` installs the distribution.
This interface makes it difficult to choose other packaging tools without an
overhaul. Because ``setup.py`` scripts allow for arbitrary execution, it
is difficult to provide a reliable user experience across environments
and history.
:pep:`517` came to
the rescue and specified a new standard for packaging and distributing Python
modules. Under PEP 517:
A ``pyproject.toml`` file is used to specify which program to use
to generate the distribution.
Two functions provided by the program, ``build_wheel(directory: str)``
and ``build_sdist(directory: str)``, create the distribution bundle in the
specified ``directory``.
The program may use its own configuration file or extend the ``.toml`` file.
The actual installation is done with ``pip install *.whl`` or
``pip install *.tar.gz``. If ``*.whl`` is available, ``pip`` will go ahead and copy
its files into the ``site-packages`` directory. If not, ``pip`` will look at
``pyproject.toml`` and decide which program to use to 'build from source'.
(Note that if there is no ``pyproject.toml`` file or the ``build-backend``
parameter is not defined, then the fall-back behaviour is to use ``setuptools``.)
With this standard, switching between packaging tools is a lot easier.
How to use it?
--------------
Start with a package that you want to distribute. You will need your source
files, a ``pyproject.toml`` file and a ``setup.cfg`` file::
~/meowpkg/
pyproject.toml
setup.cfg
meowpkg/
__init__.py
module.py
The ``pyproject.toml`` file specifies the build system (i.e. what is
being used to package your scripts and install from source). To use it with
``setuptools`` the content would be::
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"
``build_meta`` implements ``setuptools``' build system support.
The ``setuptools`` package implements the ``build_sdist``
command and the ``wheel`` package implements the ``build_wheel``
command; the latter is a dependency of the former
exposed via :pep:`517` hooks.
Use ``setuptools``' :ref:`declarative config ` to
specify the package information in ``setup.cfg``::
[metadata]
name = meowpkg
version = 0.0.1
description = a package that meows
[options]
packages = find:
.. _building:
Now generate the distribution. To build the package, use
`PyPA build `_::
$ pip install -q build
$ python -m build
And now it's done! The ``.whl`` file and ``.tar.gz`` can then be distributed
and installed::
dist/
meowpkg-0.0.1.whl
meowpkg-0.0.1.tar.gz
$ pip install dist/meowpkg-0.0.1.whl
or::
$ pip install dist/meowpkg-0.0.1.tar.gz
.. _backend-wrapper:
Dynamic build dependencies and other ``build_meta`` tweaks
----------------------------------------------------------
With the changes introduced by :pep:`517` and :pep:`518`, the
``setup_requires`` configuration field was deprecated in ``setup.cfg`` and
``setup.py``, in favour of directly listing build dependencies in the
``requires`` field of the ``build-system`` table of ``pyproject.toml``.
This approach has a series of advantages and gives package managers and
installers the ability to inspect the build requirements in advance and
perform a series of optimisations.
However, some package authors might still need to dynamically inspect the final
user's machine before deciding these requirements. One way of doing that, as
specified by :pep:`517`, is to "tweak" ``setuptools.build_meta`` by using an
:pep:`in-tree backend <517#in-tree-build-backends>`.
.. tip:: Before implementing an *in-tree* backend, have a look at
:pep:`PEP 508 <508#environment-markers>`. Most of the time, dependencies
with **environment markers** are enough to differentiate operating systems
and platforms.
If you put the following configuration in your ``pyproject.toml``:
.. code-block:: toml
[build-system]
requires = ["setuptools"]
build-backend = "backend"
backend-path = ["_custom_build"]
then you can implement a thin wrapper around ``build_meta`` in
the ``_custom_build/backend.py`` file, as shown in the following example:
.. code-block:: python
from setuptools import build_meta as _orig
from setuptools.build_meta import *
def get_requires_for_build_wheel(config_settings=None):
return _orig.get_requires_for_build_wheel(config_settings) + [...]
def get_requires_for_build_sdist(config_settings=None):
return _orig.get_requires_for_build_sdist(config_settings) + [...]
.. note::
You can override any of the functions specified in :pep:`PEP 517
<517#build-backend-interface>`, not only the ones responsible for gathering
requirements. It is important to ``import *`` so that the hooks that you
choose not to reimplement would be inherited from the setuptools' backend
automatically. This will also cover hooks that might be added in the future
like the ones that :pep:`660` declares.
.. important:: Make sure your backend script is included in the :doc:`source
distribution `, otherwise the build will fail.
This can be done by using a SCM_/VCS_ plugin (like :pypi:`setuptools-scm`
and :pypi:`setuptools-svn`), or by correctly setting up :ref:`MANIFEST.in
`.
The generated ``.tar.gz`` and ``.whl`` files are compressed archives that
can be inspected as follows:
On POSIX systems, this can be done with ``tar -tf dist/*.tar.gz``
and ``unzip -l dist/*.whl``.
On Windows systems, you can rename the ``.whl`` to ``.zip`` to be able to
inspect it from File Explorer. You can also use the above ``tar`` command in a
command prompt to inspect the ``.tar.gz`` file. Alternatively, there are GUI programs
like `7-zip`_ that handle ``.tar.gz`` and ``.whl`` files.
In general, the backend script should be present in the ``.tar.gz`` (so the
project can be built from the source) but not in the ``.whl`` (otherwise the
backend script would end up being distributed alongside your package).
See ":doc:`/userguide/package_discovery`" for more details about package
files.
.. _SCM: https://en.wikipedia.org/wiki/Software_configuration_management
.. _VCS: https://en.wikipedia.org/wiki/Version_control
.. _7-zip: https://www.7-zip.org
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/conf.py 0000644 0001751 0000173 00000021444 14467657412 015706 0 ustar 00runner docker extensions = [
'sphinx.ext.autodoc',
'jaraco.packaging.sphinx',
]
master_doc = "index"
html_theme = "furo"
# Link dates and other references in the changelog
extensions += ['rst.linker']
link_files = {
'../NEWS.rst': dict(
using=dict(
BB='https://bitbucket.org',
GH='https://github.com',
),
replace=[
dict(
pattern=r'(Issue #|\B#)(?P\d+)',
url='{package_url}/issues/{issue}',
),
dict(
pattern=r'(?m:^((?Pv?\d+(\.\d+){1,2}))\n[-=]+\n)',
with_scm='{text}\n{rev[timestamp]:%d %b %Y}\n',
),
dict(
pattern=r'PEP[- ](?P\d+)',
url='https://peps.python.org/pep-{pep_number:0>4}/',
),
dict(
pattern=r'(?\d+)',
url='{package_url}/pull/{pull}',
),
dict(
pattern=r'BB Pull Request ?#(?P\d+)',
url='{BB}/pypa/setuptools/pull-request/{bb_pull_request}',
),
dict(
pattern=r'Distribute #(?P\d+)',
url='{BB}/tarek/distribute/issue/{distribute}',
),
dict(
pattern=r'Buildout #(?P\d+)',
url='{GH}/buildout/buildout/issues/{buildout}',
),
dict(
pattern=r'Old Setuptools #(?P\d+)',
url='http://bugs.python.org/setuptools/issue{old_setuptools}',
),
dict(
pattern=r'Jython #(?P\d+)',
url='http://bugs.jython.org/issue{jython}',
),
dict(
pattern=r'(Python #|bpo-)(?P\d+)',
url='http://bugs.python.org/issue{python}',
),
dict(
pattern=r'Interop #(?P\d+)',
url='{GH}/pypa/interoperability-peps/issues/{interop}',
),
dict(
pattern=r'Pip #(?P\d+)',
url='{GH}/pypa/pip/issues/{pip}',
),
dict(
pattern=r'Packaging #(?P\d+)',
url='{GH}/pypa/packaging/issues/{packaging}',
),
dict(
pattern=r'[Pp]ackaging (?P\d+(\.\d+)+)',
url='{GH}/pypa/packaging/blob/{packaging_ver}/CHANGELOG.rst',
),
dict(
pattern=r'setuptools_svn #(?P\d+)',
url='{GH}/jaraco/setuptools_svn/issues/{setuptools_svn}',
),
dict(
pattern=r'pypa/(?P[\-\.\w]+)#(?P\d+)',
url='{GH}/pypa/{issue_repo}/issues/{issue_number}',
),
dict(
pattern=r'pypa/(?P[\-\.\w]+)@(?P[\da-f]+)',
url='{GH}/pypa/{commit_repo}/commit/{commit_number}',
),
],
),
}
# Be strict about any broken references
nitpicky = True
# Include Python intersphinx mapping to prevent failures
# jaraco/skeleton#51
extensions += ['sphinx.ext.intersphinx']
intersphinx_mapping = {
'python': ('https://docs.python.org/3', None),
}
# Preserve authored syntax for defaults
autodoc_preserve_defaults = True
intersphinx_mapping.update(
{
'pip': ('https://pip.pypa.io/en/latest', None),
'build': ('https://pypa-build.readthedocs.io/en/latest', None),
'PyPUG': ('https://packaging.python.org/en/latest/', None),
'packaging': ('https://packaging.pypa.io/en/latest/', None),
'twine': ('https://twine.readthedocs.io/en/stable/', None),
'importlib-resources': (
'https://importlib-resources.readthedocs.io/en/latest',
None,
),
}
)
# Support tooltips on references
extensions += ['hoverxref.extension']
hoverxref_auto_ref = True
hoverxref_intersphinx = [
'python',
'pip',
'build',
'PyPUG',
'packaging',
'twine',
'importlib-resources',
]
# Add support for linking usernames
github_url = 'https://github.com'
github_repo_org = 'pypa'
github_repo_name = 'setuptools'
github_repo_slug = f'{github_repo_org}/{github_repo_name}'
github_repo_url = f'{github_url}/{github_repo_slug}'
github_sponsors_url = f'{github_url}/sponsors'
extlinks = {
'user': (f'{github_sponsors_url}/%s', '@%s'), # noqa: WPS323
'pypi': ('https://pypi.org/project/%s', '%s'), # noqa: WPS323
'wiki': ('https://wikipedia.org/wiki/%s', '%s'), # noqa: WPS323
}
extensions += ['sphinx.ext.extlinks']
# Ref: https://github.com/python-attrs/attrs/pull/571/files\
# #diff-85987f48f1258d9ee486e3191495582dR82
default_role = 'any'
# HTML theme
html_theme = 'furo'
html_logo = "images/logo.svg"
html_theme_options = {
"sidebar_hide_name": True,
"light_css_variables": {
"color-brand-primary": "#336790", # "blue"
"color-brand-content": "#336790",
},
"dark_css_variables": {
"color-brand-primary": "#E5B62F", # "yellow"
"color-brand-content": "#E5B62F",
},
}
# Redirect old docs so links and references in the ecosystem don't break
extensions += ['sphinx_reredirects']
redirects = {
"userguide/keywords": "/deprecated/changed_keywords.html",
"userguide/commands": "/deprecated/commands.html",
}
# Add support for inline tabs
extensions += ['sphinx_inline_tabs']
# Support for distutils
# Ref: https://stackoverflow.com/a/30624034/595220
nitpick_ignore = [
('c:func', 'SHGetSpecialFolderPath'), # ref to MS docs
('envvar', 'DISTUTILS_DEBUG'), # undocumented
('envvar', 'HOME'), # undocumented
('envvar', 'PLAT'), # undocumented
('envvar', 'DIST_EXTRA_CONFIG'), # undocumented
('py:attr', 'CCompiler.language_map'), # undocumented
('py:attr', 'CCompiler.language_order'), # undocumented
('py:class', 'distutils.dist.Distribution'), # undocumented
('py:class', 'distutils.extension.Extension'), # undocumented
('py:class', 'BorlandCCompiler'), # undocumented
('py:class', 'CCompiler'), # undocumented
('py:class', 'CygwinCCompiler'), # undocumented
('py:class', 'distutils.dist.DistributionMetadata'), # undocumented
('py:class', 'FileList'), # undocumented
('py:class', 'IShellLink'), # ref to MS docs
('py:class', 'MSVCCompiler'), # undocumented
('py:class', 'OptionDummy'), # undocumented
('py:class', 'UnixCCompiler'), # undocumented
('py:exc', 'CompileError'), # undocumented
('py:exc', 'DistutilsExecError'), # undocumented
('py:exc', 'DistutilsFileError'), # undocumented
('py:exc', 'LibError'), # undocumented
('py:exc', 'LinkError'), # undocumented
('py:exc', 'PreprocessError'), # undocumented
('py:exc', 'setuptools.errors.PlatformError'), # sphinx cannot find it
('py:func', 'distutils.CCompiler.new_compiler'), # undocumented
# undocumented:
('py:func', 'distutils.dist.DistributionMetadata.read_pkg_file'),
('py:func', 'distutils.file_util._copy_file_contents'), # undocumented
('py:func', 'distutils.log.debug'), # undocumented
('py:func', 'distutils.spawn.find_executable'), # undocumented
('py:func', 'distutils.spawn.spawn'), # undocumented
# TODO: check https://docutils.rtfd.io in the future
('py:mod', 'docutils'), # there's no Sphinx site documenting this
]
# Allow linking objects on other Sphinx sites seamlessly:
intersphinx_mapping.update(
python=('https://docs.python.org/3', None),
)
# Add support for the unreleased "next-version" change notes
extensions += ['sphinxcontrib.towncrier']
# Extension needs a path from here to the towncrier config.
towncrier_draft_working_directory = '..'
# Avoid an empty section for unpublished changes.
towncrier_draft_include_empty = False
# sphinx-contrib/sphinxcontrib-towncrier#81
towncrier_draft_config_path = 'towncrier.toml'
extensions += ['jaraco.tidelift']
# Add icons (aka "favicons") to documentation
extensions += ['sphinx_favicon']
html_static_path = ['images'] # should contain the folder with icons
# Add support for nice Not Found 404 pages
# extensions += ['notfound.extension'] # readthedocs/sphinx-notfound-page#219
# List of dicts with HTML attributes
# static-file points to files in the html_static_path (href is computed)
favicons = [
{ # "Catch-all" goes first, otherwise some browsers will overwrite
"rel": "icon",
"type": "image/svg+xml",
"static-file": "logo-symbol-only.svg",
"sizes": "any",
},
{ # Version with thicker strokes for better visibility at smaller sizes
"rel": "icon",
"type": "image/svg+xml",
"static-file": "favicon.svg",
"sizes": "16x16 24x24 32x32 48x48",
},
# rel="apple-touch-icon" does not support SVG yet
]
././@PaxHeader 0000000 0000000 0000000 00000000034 00000000000 010212 x ustar 00 28 mtime=1692360483.4875476
setuptools-68.1.2/docs/deprecated/ 0000755 0001751 0000173 00000000000 14467657443 016506 5 ustar 00runner docker ././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/changed_keywords.rst 0000644 0001751 0000173 00000004201 14467657412 022551 0 ustar 00runner docker New and Changed ``setup()`` Keywords
====================================
This document tracks historical differences between ``setuptools`` and
``distutils``.
Since ``distutils`` was scheduled for removal from the standard library in
Python 3.12, and ``setuptools`` started its adoption, these differences became less
relevant.
Please check :doc:`/references/keywords` for a complete list of keyword
arguments that can be passed to the ``setuptools.setup()`` function and
a their full description.
.. tab:: Supported by both ``distutils`` and ``setuptoools``
``name`` string
``version`` string
``description`` string
``long_description`` string
``long_description_content_type`` string
``author`` string
``author_email`` string
``maintainer`` string
``maintainer_email`` string
``url`` string
``download_url`` string
``packages`` list
``py_modules`` list
``scripts`` list
``ext_package`` string
``ext_modules`` list
``classifiers`` list
``distclass`` Distribution subclass
``script_name`` string
``script_args`` list
``options`` dictionary
``license`` string
``license_file`` string **deprecated**
``license_files`` list
``keywords`` string or list
``platforms`` list
``cmdclass`` dictionary
``data_files`` list **deprecated**
``package_dir`` dictionary
``requires`` string or list **deprecated**
``obsoletes`` list **deprecated**
``provides`` list
.. tab:: Added or changed by ``setuptoools``
``include_package_data`` bool
``exclude_package_data`` dictionary
``package_data`` dictionary
``zip_safe`` bool
``install_requires`` string or list
``entry_points`` dictionary
``extras_require`` dictionary
``python_requires`` string
``setup_requires`` string or list **deprecated**
``dependency_links`` list **deprecated**
``namespace_packages`` list
``test_suite`` string or function **deprecated**
``tests_require`` string or list **deprecated**
``test_loader`` class **deprecated**
``eager_resources`` list
``project_urls`` dictionary
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/commands.rst 0000644 0001751 0000173 00000071752 14467657412 021051 0 ustar 00runner docker ===============================
Running ``setuptools`` commands
===============================
Historically, ``setuptools`` allowed running commands via a ``setup.py`` script
at the root of a Python project, as indicated in the examples below::
python setup.py --help
python setup.py --help-commands
python setup.py --version
python setup.py sdist
python setup.py bdist_wheel
You could also run commands in other circumstances:
* ``setuptools`` projects without ``setup.py`` (e.g., ``setup.cfg``-only)::
python -c "from setuptools import setup; setup()" --help
* ``distutils`` projects (with a ``setup.py`` importing ``distutils``)::
python -c "import setuptools; with open('setup.py') as f: exec(compile(f.read(), 'setup.py', 'exec'))" develop
That is, you can simply list the normal setup commands and options following the quoted part.
.. warning::
While it is perfectly fine that users write ``setup.py`` files to configure
a package build (e.g. to specify binary extensions or customize commands),
on recent versions of ``setuptools``, running ``python setup.py`` directly
as a script is considered **deprecated**. This also means that users should
avoid running commands directly via ``python setup.py ``.
If you want to create :term:`sdist ` or :term:`wheel`
distributions the recommendation is to use the command line tool provided by :pypi:`build`::
pip install build # needs to be installed first
python -m build # builds both sdist and wheel
python -m build --sdist
python -m build --wheel
Build will automatically download ``setuptools`` and build the package in an
isolated environment. You can also specify specific versions of
``setuptools``, by setting the :doc:`build requirements in pyproject.toml
`.
If you want to install a package, you can use :pypi:`pip` or :pypi:`installer`::
pip install /path/to/wheel/file.whl
pip install /path/to/sdist/file.tar.gz
pip install . # replacement for python setup.py install
pip install --editable . # replacement for python setup.py develop
pip install installer # needs to be installed first
python -m installer /path/to/wheel/file.whl
-----------------
Command Reference
-----------------
.. _alias:
``alias`` - Define shortcuts for commonly used commands
=======================================================
Sometimes, you need to use the same commands over and over, but you can't
necessarily set them as defaults. For example, if you produce both development
snapshot releases and "stable" releases of a project, you may want to put
the distributions in different places, or use different ``egg_info`` tagging
options, etc. In these cases, it doesn't make sense to set the options in
a distutils configuration file, because the values of the options changed based
on what you're trying to do.
Setuptools therefore allows you to define "aliases" - shortcut names for
an arbitrary string of commands and options, using ``setup.py alias aliasname
expansion``, where aliasname is the name of the new alias, and the remainder of
the command line supplies its expansion. For example, this command defines
a sitewide alias called "daily", that sets various ``egg_info`` tagging
options::
setup.py alias --global-config daily egg_info --tag-build=development
Once the alias is defined, it can then be used with other setup commands,
e.g.::
setup.py daily bdist_egg # generate a daily-build .egg file
setup.py daily sdist # generate a daily-build source distro
setup.py daily sdist bdist_egg # generate both
The above commands are interpreted as if the word ``daily`` were replaced with
``egg_info --tag-build=development``.
Note that setuptools will expand each alias *at most once* in a given command
line. This serves two purposes. First, if you accidentally create an alias
loop, it will have no effect; you'll instead get an error message about an
unknown command. Second, it allows you to define an alias for a command, that
uses that command. For example, this (project-local) alias::
setup.py alias bdist_egg bdist_egg rotate -k1 -m.egg
redefines the ``bdist_egg`` command so that it always runs the ``rotate``
command afterwards to delete all but the newest egg file. It doesn't loop
indefinitely on ``bdist_egg`` because the alias is only expanded once when
used.
You can remove a defined alias with the ``--remove`` (or ``-r``) option, e.g.::
setup.py alias --global-config --remove daily
would delete the "daily" alias we defined above.
Aliases can be defined on a project-specific, per-user, or sitewide basis. The
default is to define or remove a project-specific alias, but you can use any of
the `configuration file options`_ (listed under the `saveopts`_ command, below)
to determine which distutils configuration file an aliases will be added to
(or removed from).
Note that if you omit the "expansion" argument to the ``alias`` command,
you'll get output showing that alias' current definition (and what
configuration file it's defined in). If you omit the alias name as well,
you'll get a listing of all current aliases along with their configuration
file locations.
``bdist_egg`` - Create a Python Egg for the project
===================================================
.. warning::
**eggs** are deprecated in favor of wheels, and not supported by pip.
This command generates a Python Egg (``.egg`` file) for the project. Python
Eggs are the preferred binary distribution format for EasyInstall, because they
are cross-platform (for "pure" packages), directly importable, and contain
project metadata including scripts and information about the project's
dependencies. They can be simply downloaded and added to ``sys.path``
directly, or they can be placed in a directory on ``sys.path`` and then
automatically discovered by the egg runtime system.
This command runs the `egg_info`_ command (if it hasn't already run) to update
the project's metadata (``.egg-info``) directory. If you have added any extra
metadata files to the ``.egg-info`` directory, those files will be included in
the new egg file's metadata directory, for use by the egg runtime system or by
any applications or frameworks that use that metadata.
You won't usually need to specify any special options for this command; just
use ``bdist_egg`` and you're done. But there are a few options that may
be occasionally useful:
``--dist-dir=DIR, -d DIR``
Set the directory where the ``.egg`` file will be placed. If you don't
supply this, then the ``--dist-dir`` setting of the ``bdist`` command
will be used, which is usually a directory named ``dist`` in the project
directory.
``--plat-name=PLATFORM, -p PLATFORM``
Set the platform name string that will be embedded in the egg's filename
(assuming the egg contains C extensions). This can be used to override
the distutils default platform name with something more meaningful. Keep
in mind, however, that the egg runtime system expects to see eggs with
distutils platform names, so it may ignore or reject eggs with non-standard
platform names. Similarly, the EasyInstall program may ignore them when
searching web pages for download links. However, if you are
cross-compiling or doing some other unusual things, you might find a use
for this option.
``--exclude-source-files``
Don't include any modules' ``.py`` files in the egg, just compiled Python,
C, and data files. (Note that this doesn't affect any ``.py`` files in the
EGG-INFO directory or its subdirectories, since for example there may be
scripts with a ``.py`` extension which must still be retained.) We don't
recommend that you use this option except for packages that are being
bundled for proprietary end-user applications, or for "embedded" scenarios
where space is at an absolute premium. On the other hand, if your package
is going to be installed and used in compressed form, you might as well
exclude the source because Python's ``traceback`` module doesn't currently
understand how to display zipped source code anyway, or how to deal with
files that are in a different place from where their code was compiled.
There are also some options you will probably never need, but which are there
because they were copied from similar ``bdist`` commands used as an example for
creating this one. They may be useful for testing and debugging, however,
which is why we kept them:
``--keep-temp, -k``
Keep the contents of the ``--bdist-dir`` tree around after creating the
``.egg`` file.
``--bdist-dir=DIR, -b DIR``
Set the temporary directory for creating the distribution. The entire
contents of this directory are zipped to create the ``.egg`` file, after
running various installation commands to copy the package's modules, data,
and extensions here.
``--skip-build``
Skip doing any "build" commands; just go straight to the
install-and-compress phases.
.. _develop:
``develop`` - Deploy the project source in "Development Mode"
=============================================================
This command allows you to deploy your project's source for use in one or more
"staging areas" where it will be available for importing. This deployment is
done in such a way that changes to the project source are immediately available
in the staging area(s), without needing to run a build or install step after
each change.
The ``develop`` command works by creating an ``.egg-link`` file (named for the
project) in the given staging area. If the staging area is Python's
``site-packages`` directory, it also updates an ``easy-install.pth`` file so
that the project is on ``sys.path`` by default for all programs run using that
Python installation.
The ``develop`` command also installs wrapper scripts in the staging area (or
a separate directory, as specified) that will ensure the project's dependencies
are available on ``sys.path`` before running the project's source scripts.
And, it ensures that any missing project dependencies are available in the
staging area, by downloading and installing them if necessary.
Last, but not least, the ``develop`` command invokes the ``build_ext -i``
command to ensure any C extensions in the project have been built and are
up-to-date, and the ``egg_info`` command to ensure the project's metadata is
updated (so that the runtime and wrappers know what the project's dependencies
are). If you make any changes to the project's setup script or C extensions,
you should rerun the ``develop`` command against all relevant staging areas to
keep the project's scripts, metadata and extensions up-to-date. Most other
kinds of changes to your project should not require any build operations or
rerunning ``develop``, but keep in mind that even minor changes to the setup
script (e.g. changing an entry point definition) require you to re-run the
``develop`` or ``test`` commands to keep the distribution updated.
Here are some of the options that the ``develop`` command accepts. Note that
they affect the project's dependencies as well as the project itself, so if you
have dependencies that need to be installed and you use ``--exclude-scripts``
(for example), the dependencies' scripts will not be installed either! For
this reason, you may want to use pip to install the project's dependencies
before using the ``develop`` command, if you need finer control over the
installation options for dependencies.
``--uninstall, -u``
Un-deploy the current project. You may use the ``--install-dir`` or ``-d``
option to designate the staging area. The created ``.egg-link`` file will
be removed, if present and it is still pointing to the project directory.
The project directory will be removed from ``easy-install.pth`` if the
staging area is Python's ``site-packages`` directory.
Note that this option currently does *not* uninstall script wrappers! You
must uninstall them yourself, or overwrite them by using pip to install a
different version of the package. You can also avoid installing script
wrappers in the first place, if you use the ``--exclude-scripts`` (aka
``-x``) option when you run ``develop`` to deploy the project.
``--multi-version, -m``
"Multi-version" mode. Specifying this option prevents ``develop`` from
adding an ``easy-install.pth`` entry for the project(s) being deployed, and
if an entry for any version of a project already exists, the entry will be
removed upon successful deployment. In multi-version mode, no specific
version of the package is available for importing, unless you use
``pkg_resources.require()`` to put it on ``sys.path``, or you are running
a wrapper script generated by ``setuptools``. (In which case the wrapper
script calls ``require()`` for you.)
Note that if you install to a directory other than ``site-packages``,
this option is automatically in effect, because ``.pth`` files can only be
used in ``site-packages`` (at least in Python 2.3 and 2.4). So, if you use
the ``--install-dir`` or ``-d`` option (or they are set via configuration
file(s)) your project and its dependencies will be deployed in
multi-version mode.
``--install-dir=DIR, -d DIR``
Set the installation directory (staging area). If this option is not
directly specified on the command line or in a distutils configuration
file, the distutils default installation location is used. Normally, this
will be the ``site-packages`` directory, but if you are using distutils
configuration files, setting things like ``prefix`` or ``install_lib``,
then those settings are taken into account when computing the default
staging area.
``--script-dir=DIR, -s DIR``
Set the script installation directory. If you don't supply this option
(via the command line or a configuration file), but you *have* supplied
an ``--install-dir`` (via command line or config file), then this option
defaults to the same directory, so that the scripts will be able to find
their associated package installation. Otherwise, this setting defaults
to the location where the distutils would normally install scripts, taking
any distutils configuration file settings into account.
``--exclude-scripts, -x``
Don't deploy script wrappers. This is useful if you don't want to disturb
existing versions of the scripts in the staging area.
``--always-copy, -a``
Copy all needed distributions to the staging area, even if they
are already present in another directory on ``sys.path``. By default, if
a requirement can be met using a distribution that is already available in
a directory on ``sys.path``, it will not be copied to the staging area.
``--egg-path=DIR``
Force the generated ``.egg-link`` file to use a specified relative path
to the source directory. This can be useful in circumstances where your
installation directory is being shared by code running under multiple
platforms (e.g. Mac and Windows) which have different absolute locations
for the code under development, but the same *relative* locations with
respect to the installation directory. If you use this option when
installing, you must supply the same relative path when uninstalling.
In addition to the above options, the ``develop`` command also accepts all of
the same options accepted by ``easy_install``. If you've configured any
``easy_install`` settings in your ``setup.cfg`` (or other distutils config
files), the ``develop`` command will use them as defaults, unless you override
them in a ``[develop]`` section or on the command line.
.. _egg_info:
``egg_info`` - Create egg metadata and set build tags
=====================================================
This command performs two operations: it updates a project's ``.egg-info``
metadata directory (used by the ``bdist_egg``, ``develop``, and ``test``
commands), and it allows you to temporarily change a project's version string,
to support "daily builds" or "snapshot" releases. It is run automatically by
the ``sdist``, ``bdist_egg``, ``develop``, and ``test`` commands in order to
update the project's metadata, but you can also specify it explicitly in order
to temporarily change the project's version string while executing other
commands. (It also generates the ``.egg-info/SOURCES.txt`` manifest file, which
is used when you are building source distributions.)
In addition to writing the core egg metadata defined by ``setuptools`` and
required by ``pkg_resources``, this command can be extended to write other
metadata files as well, by defining entry points in the ``egg_info.writers``
group. See the section on :ref:`Adding new EGG-INFO Files` below for more details.
Note that using additional metadata writers may require you to include a
``setup_requires`` argument to ``setup()`` in order to ensure that the desired
writers are available on ``sys.path``.
Release Tagging Options
-----------------------
The following options can be used to modify the project's version string for
all remaining commands on the setup command line. The options are processed
in the order shown, so if you use more than one, the requested tags will be
added in the following order:
``--tag-build=NAME, -b NAME``
Append NAME to the project's version string. Due to the way setuptools
processes "pre-release" version suffixes beginning with the letters "a"
through "e" (like "alpha", "beta", and "candidate"), you will usually want
to use a tag like ".build" or ".dev", as this will cause the version number
to be considered *lower* than the project's default version. (If you
want to make the version number *higher* than the default version, you can
always leave off --tag-build and then use one or both of the following
options.)
If you have a default build tag set in your ``setup.cfg``, you can suppress
it on the command line using ``-b ""`` or ``--tag-build=""`` as an argument
to the ``egg_info`` command.
``--tag-date, -d``
Add a date stamp of the form "-YYYYMMDD" (e.g. "-20050528") to the
project's version number.
``--no-date, -D``
Don't include a date stamp in the version number. This option is included
so you can override a default setting in ``setup.cfg``.
(Note: Because these options modify the version number used for source and
binary distributions of your project, you should first make sure that you know
how the resulting version numbers will be interpreted by automated tools
like pip. See the section above on :ref:`Specifying Your Project's Version` for an
explanation of pre- and post-release tags, as well as tips on how to choose and
verify a versioning scheme for your project.)
For advanced uses, there is one other option that can be set, to change the
location of the project's ``.egg-info`` directory. Commands that need to find
the project's source directory or metadata should get it from this setting:
Other ``egg_info`` Options
--------------------------
``--egg-base=SOURCEDIR, -e SOURCEDIR``
Specify the directory that should contain the .egg-info directory. This
should normally be the root of your project's source tree (which is not
necessarily the same as your project directory; some projects use a ``src``
or ``lib`` subdirectory as the source root). You should not normally need
to specify this directory, as it is normally determined from the
``package_dir`` argument to the ``setup()`` function, if any. If there is
no ``package_dir`` set, this option defaults to the current directory.
``egg_info`` Examples
---------------------
Creating a dated "nightly build" snapshot egg::
setup.py egg_info --tag-date --tag-build=DEV bdist_egg
Creating a release with no version tags, even if some default tags are
specified in ``setup.cfg``::
setup.py egg_info -RDb "" sdist bdist_egg
(Notice that ``egg_info`` must always appear on the command line *before* any
commands that you want the version changes to apply to.)
.. _rotate:
``rotate`` - Delete outdated distribution files
===============================================
As you develop new versions of your project, your distribution (``dist``)
directory will gradually fill up with older source and/or binary distribution
files. The ``rotate`` command lets you automatically clean these up, keeping
only the N most-recently modified files matching a given pattern.
``--match=PATTERNLIST, -m PATTERNLIST``
Comma-separated list of glob patterns to match. This option is *required*.
The project name and ``-*`` is prepended to the supplied patterns, in order
to match only distributions belonging to the current project (in case you
have a shared distribution directory for multiple projects). Typically,
you will use a glob pattern like ``.zip`` or ``.egg`` to match files of
the specified type. Note that each supplied pattern is treated as a
distinct group of files for purposes of selecting files to delete.
``--keep=COUNT, -k COUNT``
Number of matching distributions to keep. For each group of files
identified by a pattern specified with the ``--match`` option, delete all
but the COUNT most-recently-modified files in that group. This option is
*required*.
``--dist-dir=DIR, -d DIR``
Directory where the distributions are. This defaults to the value of the
``bdist`` command's ``--dist-dir`` option, which will usually be the
project's ``dist`` subdirectory.
**Example 1**: Delete all .tar.gz files from the distribution directory, except
for the 3 most recently modified ones::
setup.py rotate --match=.tar.gz --keep=3
**Example 2**: Delete all Python 2.3 or Python 2.4 eggs from the distribution
directory, except the most recently modified one for each Python version::
setup.py rotate --match=-py2.3*.egg,-py2.4*.egg --keep=1
.. _saveopts:
``saveopts`` - Save used options to a configuration file
========================================================
Finding and editing ``distutils`` configuration files can be a pain, especially
since you also have to translate the configuration options from command-line
form to the proper configuration file format. You can avoid these hassles by
using the ``saveopts`` command. Just add it to the command line to save the
options you used. For example, this command builds the project using
the ``mingw32`` C compiler, then saves the --compiler setting as the default
for future builds (even those run implicitly by the ``install`` command)::
setup.py build --compiler=mingw32 saveopts
The ``saveopts`` command saves all options for every command specified on the
command line to the project's local ``setup.cfg`` file, unless you use one of
the `configuration file options`_ to change where the options are saved. For
example, this command does the same as above, but saves the compiler setting
to the site-wide (global) distutils configuration::
setup.py build --compiler=mingw32 saveopts -g
Note that it doesn't matter where you place the ``saveopts`` command on the
command line; it will still save all the options specified for all commands.
For example, this is another valid way to spell the last example::
setup.py saveopts -g build --compiler=mingw32
Note, however, that all of the commands specified are always run, regardless of
where ``saveopts`` is placed on the command line.
Configuration File Options
--------------------------
Normally, settings such as options and aliases are saved to the project's
local ``setup.cfg`` file. But you can override this and save them to the
global or per-user configuration files, or to a manually-specified filename.
``--global-config, -g``
Save settings to the global ``distutils.cfg`` file inside the ``distutils``
package directory. You must have write access to that directory to use
this option. You also can't combine this option with ``-u`` or ``-f``.
``--user-config, -u``
Save settings to the current user's ``~/.pydistutils.cfg`` (POSIX) or
``$HOME/pydistutils.cfg`` (Windows) file. You can't combine this option
with ``-g`` or ``-f``.
``--filename=FILENAME, -f FILENAME``
Save settings to the specified configuration file to use. You can't
combine this option with ``-g`` or ``-u``. Note that if you specify a
non-standard filename, the ``distutils`` and ``setuptools`` will not
use the file's contents. This option is mainly included for use in
testing.
These options are used by other ``setuptools`` commands that modify
configuration files, such as the `alias`_ and `setopt`_ commands.
.. _setopt:
``setopt`` - Set a distutils or setuptools option in a config file
==================================================================
This command is mainly for use by scripts, but it can also be used as a quick
and dirty way to change a distutils configuration option without having to
remember what file the options are in and then open an editor.
**Example 1**. Set the default C compiler to ``mingw32`` (using long option
names)::
setup.py setopt --command=build --option=compiler --set-value=mingw32
**Example 2**. Remove any setting for the distutils default package
installation directory (short option names)::
setup.py setopt -c install -o install_lib -r
Options for the ``setopt`` command:
``--command=COMMAND, -c COMMAND``
Command to set the option for. This option is required.
``--option=OPTION, -o OPTION``
The name of the option to set. This option is required.
``--set-value=VALUE, -s VALUE``
The value to set the option to. Not needed if ``-r`` or ``--remove`` is
set.
``--remove, -r``
Remove (unset) the option, instead of setting it.
In addition to the above options, you may use any of the `configuration file
options`_ (listed under the `saveopts`_ command, above) to determine which
distutils configuration file the option will be added to (or removed from).
.. _test:
``test`` - Build package and run a unittest suite
=================================================
.. 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 `_.
When doing test-driven development, or running automated builds that need
testing before they are deployed for downloading or use, it's often useful
to be able to run a project's unit tests without actually deploying the project
anywhere, even using the ``develop`` command. The ``test`` command runs a
project's unit tests without actually deploying it, by temporarily putting the
project's source on ``sys.path``, after first running ``build_ext -i`` and
``egg_info`` to ensure that any C extensions and project metadata are
up-to-date.
To use this command, your project's tests must be wrapped in a ``unittest``
test suite by either a function, a ``TestCase`` class or method, or a module
or package containing ``TestCase`` classes. If the named suite is a module,
and the module has an ``additional_tests()`` function, it is called and the
result (which must be a ``unittest.TestSuite``) is 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. (Note: if your project specifies
a ``test_loader``, the rules for processing the chosen ``test_suite`` may
differ; see the :ref:`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
package that does not support this, we suggest you encourage its developers to
implement test suite support, as this is a convenient and standard way to
aggregate a collection of tests to be run under a common test harness.
By default, tests will be run in the "verbose" mode of the ``unittest``
package's text test runner, but you can get the "quiet" mode (just dots) if
you supply the ``-q`` or ``--quiet`` option, either as a global option to
the setup script (e.g. ``setup.py -q test``) or as an option for the ``test``
command itself (e.g. ``setup.py test -q``). There is one other option
available:
``--test-suite=NAME, -s NAME``
Specify the test suite (or module, class, or method) to be run
(e.g. ``some_module.test_suite``). The default for this option can be
set by giving a ``test_suite`` argument to the ``setup()`` function, e.g.::
setup(
# ...
test_suite="my_package.tests.test_all"
)
If you did not set a ``test_suite`` in your ``setup()`` call, and do not
provide a ``--test-suite`` option, an error will occur.
New in 41.5.0: Deprecated the test command.
.. _upload:
``upload`` - Upload source and/or egg distributions to PyPI
===========================================================
The ``upload`` command was deprecated in version 40.0 and removed in version
42.0. Use `twine `_ instead.
For more information on the current best practices in uploading your packages
to PyPI, see the Python Packaging User Guide's "Packaging Python Projects"
tutorial specifically the section on `uploading the distribution archives
`_.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/dependency_links.rst 0000644 0001751 0000173 00000005453 14467657412 022561 0 ustar 00runner docker Specifying dependencies that aren't in PyPI via ``dependency_links``
====================================================================
.. warning::
Dependency links support has been dropped by pip starting with version
19.0 (released 2019-01-22).
If your project depends on packages that don't exist on PyPI, you *may* still be
able to depend on them if they are available for download as:
- an egg, in the standard distutils ``sdist`` format,
- a single ``.py`` file, or
- a VCS repository (Subversion, Mercurial, or Git).
You need to add some URLs to the ``dependency_links`` argument to ``setup()``.
The URLs must be either:
1. direct download URLs,
2. the URLs of web pages that contain direct download links, or
3. the repository's URL
In general, it's better to link to web pages, because it is usually less
complex to update a web page than to release a new version of your project.
You can also use a SourceForge ``showfiles.php`` link in the case where a
package you depend on is distributed via SourceForge.
If you depend on a package that's distributed as a single ``.py`` file, you
must include an ``"#egg=project-version"`` suffix to the URL, to give a project
name and version number. (Be sure to escape any dashes in the name or version
by replacing them with underscores.) EasyInstall will recognize this suffix
and automatically create a trivial ``setup.py`` to wrap the single ``.py`` file
as an egg.
In the case of a VCS checkout, you should also append ``#egg=project-version``
in order to identify for what package that checkout should be used. You can
append ``@REV`` to the URL's path (before the fragment) to specify a revision.
Additionally, you can also force the VCS being used by prepending the URL with
a certain prefix. Currently available are:
- ``svn+URL`` for Subversion,
- ``git+URL`` for Git, and
- ``hg+URL`` for Mercurial
A more complete example would be:
``vcs+proto://host/path@revision#egg=project-version``
Be careful with the version. It should match the one inside the project files.
If you want to disregard the version, you have to omit it both in the
``requires`` and in the URL's fragment.
This will do a checkout (or a clone, in Git and Mercurial parlance) to a
temporary folder and run ``setup.py bdist_egg``.
The ``dependency_links`` option takes the form of a list of URL strings. For
example, this will cause a search of the specified page for eggs or source
distributions, if the package's dependencies aren't already installed:
.. tab:: setup.cfg
.. code-block:: ini
[options]
#...
dependency_links = http://peak.telecommunity.com/snapshots/
.. tab:: setup.py
.. code-block:: python
setup(
...,
dependency_links=[
"http://peak.telecommunity.com/snapshots/",
],
)
././@PaxHeader 0000000 0000000 0000000 00000000034 00000000000 010212 x ustar 00 28 mtime=1692360483.4875476
setuptools-68.1.2/docs/deprecated/distutils/ 0000755 0001751 0000173 00000000000 14467657443 020532 5 ustar 00runner docker ././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/_setuptools_disclaimer.rst 0000644 0001751 0000173 00000000350 14467657412 026032 0 ustar 00runner docker .. note::
This document is being retained solely until the ``setuptools`` documentation
at https://setuptools.pypa.io/en/latest/setuptools.html
independently covers all of the relevant information currently included here.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/apiref.rst 0000644 0001751 0000173 00000273044 14467657412 022540 0 ustar 00runner docker .. _api-reference:
*************
API Reference
*************
.. seealso::
`New and changed setup.py arguments in setuptools`_
The ``setuptools`` project adds new capabilities to the ``setup`` function
and other APIs, makes the API consistent across different Python versions,
and is hence recommended over using ``distutils`` directly.
.. _New and changed setup.py arguments in setuptools: https://setuptools.pypa.io/en/latest/setuptools.html#new-and-changed-setup-keywords
.. include:: ./_setuptools_disclaimer.rst
:mod:`distutils.core` --- Core Distutils functionality
======================================================
.. module:: distutils.core
:synopsis: The core Distutils functionality
The :mod:`distutils.core` module is the only module that needs to be installed
to use the Distutils. It provides the :func:`setup` (which is called from the
setup script). Indirectly provides the :class:`distutils.dist.Distribution` and
:class:`distutils.cmd.Command` class.
.. function:: setup(arguments)
The basic do-everything function that does most everything you could ever ask
for from a Distutils method.
The setup function takes a large number of arguments. These are laid out in the
following table.
.. tabularcolumns:: |l|L|L|
+--------------------+--------------------------------+-------------------------------------------------------------+
| argument name | value | type |
+====================+================================+=============================================================+
| *name* | The name of the package | a string |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *version* | The version number of the | a string |
| | package; see | |
| | :mod:`distutils.version` | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *description* | A single line describing the | a string |
| | package | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *long_description* | Longer description of the | a string |
| | package | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *author* | The name of the package author | a string |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *author_email* | The email address of the | a string |
| | package author | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *maintainer* | The name of the current | a string |
| | maintainer, if different from | |
| | the author. Note that if | |
| | the maintainer is provided, | |
| | distutils will use it as the | |
| | author in :file:`PKG-INFO` | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *maintainer_email* | The email address of the | a string |
| | current maintainer, if | |
| | different from the author | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *url* | A URL for the package | a string |
| | (homepage) | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *download_url* | A URL to download the package | a string |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *packages* | A list of Python packages that | a list of strings |
| | distutils will manipulate | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *py_modules* | A list of Python modules that | a list of strings |
| | distutils will manipulate | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *scripts* | A list of standalone script | a list of strings |
| | files to be built and | |
| | installed | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *ext_modules* | A list of Python extensions to | a list of instances of |
| | be built | :class:`distutils.core.Extension` |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *classifiers* | A list of categories for the | a list of strings; valid classifiers are listed on `PyPI |
| | package | `_. |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *distclass* | the :class:`Distribution` | a subclass of |
| | class to use | :class:`distutils.core.Distribution` |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *script_name* | The name of the setup.py | a string |
| | script - defaults to | |
| | ``sys.argv[0]`` | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *script_args* | Arguments to supply to the | a list of strings |
| | setup script | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *options* | default options for the setup | a dictionary |
| | script | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *license* | The license for the package | a string |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *keywords* | Descriptive meta-data, see | a list of strings or a comma-separated string |
| | :pep:`314` | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *platforms* | | a list of strings or a comma-separated string |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *cmdclass* | A mapping of command names to | a dictionary |
| | :class:`Command` subclasses | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *data_files* | A list of data files to | a list |
| | install | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *package_dir* | A mapping of package to | a dictionary |
| | directory names | |
+--------------------+--------------------------------+-------------------------------------------------------------+
.. function:: run_setup(script_name[, script_args=None, stop_after='run'])
Run a setup script in a somewhat controlled environment, and return the
:class:`distutils.dist.Distribution` instance that drives things. This is
useful if you need to find out the distribution meta-data (passed as keyword
args from *script* to :func:`setup`), or the contents of the config files or
command-line.
*script_name* is a file that will be read and run with :func:`exec`. ``sys.argv[0]``
will be replaced with *script* for the duration of the call. *script_args* is a
list of strings; if supplied, ``sys.argv[1:]`` will be replaced by *script_args*
for the duration of the call.
*stop_after* tells :func:`setup` when to stop processing; possible values:
.. tabularcolumns:: |l|L|
+---------------+---------------------------------------------+
| value | description |
+===============+=============================================+
| *init* | Stop after the :class:`Distribution` |
| | instance has been created and populated |
| | with the keyword arguments to :func:`setup` |
+---------------+---------------------------------------------+
| *config* | Stop after config files have been parsed |
| | (and their data stored in the |
| | :class:`Distribution` instance) |
+---------------+---------------------------------------------+
| *commandline* | Stop after the command-line |
| | (``sys.argv[1:]`` or *script_args*) have |
| | been parsed (and the data stored in the |
| | :class:`Distribution` instance.) |
+---------------+---------------------------------------------+
| *run* | Stop after all commands have been run (the |
| | same as if :func:`setup` had been called |
| | in the usual way). This is the default |
| | value. |
+---------------+---------------------------------------------+
In addition, the :mod:`distutils.core` module exposed a number of classes that
live elsewhere.
* :class:`~distutils.extension.Extension` from :mod:`distutils.extension`
* :class:`~distutils.cmd.Command` from :mod:`distutils.cmd`
* :class:`~distutils.dist.Distribution` from :mod:`distutils.dist`
A short description of each of these follows, but see the relevant module for
the full reference.
.. class:: Extension
The Extension class describes a single C or C++ extension module in a setup
script. It accepts the following keyword arguments in its constructor:
.. tabularcolumns:: |l|L|l|
+------------------------+--------------------------------+---------------------------+
| argument name | value | type |
+========================+================================+===========================+
| *name* | the full name of the | a string |
| | extension, including any | |
| | packages --- ie. *not* a | |
| | filename or pathname, but | |
| | Python dotted name | |
+------------------------+--------------------------------+---------------------------+
| *sources* | list of source filenames, | a list of strings |
| | relative to the distribution | |
| | root (where the setup script | |
| | lives), in Unix form | |
| | (slash-separated) for | |
| | portability. | |
| | Source files may be C, C++, | |
| | SWIG (.i), platform-specific | |
| | resource files, or whatever | |
| | else is recognized by the | |
| | :command:`build_ext` command | |
| | as source for a Python | |
| | extension. | |
+------------------------+--------------------------------+---------------------------+
| *include_dirs* | list of directories to search | a list of strings |
| | for C/C++ header files (in | |
| | Unix form for portability) | |
+------------------------+--------------------------------+---------------------------+
| *define_macros* | list of macros to define; each | a list of tuples |
| | macro is defined using a | |
| | 2-tuple ``(name, value)``, | |
| | where *value* is | |
| | either the string to define it | |
| | to or ``None`` to define it | |
| | without a particular value | |
| | (equivalent of ``#define FOO`` | |
| | in source or :option:`!-DFOO` | |
| | on Unix C compiler command | |
| | line) | |
+------------------------+--------------------------------+---------------------------+
| *undef_macros* | list of macros to undefine | a list of strings |
| | explicitly | |
+------------------------+--------------------------------+---------------------------+
| *library_dirs* | list of directories to search | a list of strings |
| | for C/C++ libraries at link | |
| | time | |
+------------------------+--------------------------------+---------------------------+
| *libraries* | list of library names (not | a list of strings |
| | filenames or paths) to link | |
| | against | |
+------------------------+--------------------------------+---------------------------+
| *runtime_library_dirs* | list of directories to search | a list of strings |
| | for C/C++ libraries at run | |
| | time (for shared extensions, | |
| | this is when the extension is | |
| | loaded) | |
+------------------------+--------------------------------+---------------------------+
| *extra_objects* | list of extra files to link | a list of strings |
| | with (eg. object files not | |
| | implied by 'sources', static | |
| | library that must be | |
| | explicitly specified, binary | |
| | resource files, etc.) | |
+------------------------+--------------------------------+---------------------------+
| *extra_compile_args* | any extra platform- and | a list of strings |
| | compiler-specific information | |
| | to use when compiling the | |
| | source files in 'sources'. For | |
| | platforms and compilers where | |
| | a command line makes sense, | |
| | this is typically a list of | |
| | command-line arguments, but | |
| | for other platforms it could | |
| | be anything. | |
+------------------------+--------------------------------+---------------------------+
| *extra_link_args* | any extra platform- and | a list of strings |
| | compiler-specific information | |
| | to use when linking object | |
| | files together to create the | |
| | extension (or to create a new | |
| | static Python interpreter). | |
| | Similar interpretation as for | |
| | 'extra_compile_args'. | |
+------------------------+--------------------------------+---------------------------+
| *export_symbols* | list of symbols to be exported | a list of strings |
| | from a shared extension. Not | |
| | used on all platforms, and not | |
| | generally necessary for Python | |
| | extensions, which typically | |
| | export exactly one symbol: | |
| | ``init`` + extension_name. | |
+------------------------+--------------------------------+---------------------------+
| *depends* | list of files that the | a list of strings |
| | extension depends on | |
+------------------------+--------------------------------+---------------------------+
| *language* | extension language (i.e. | a string |
| | ``'c'``, ``'c++'``, | |
| | ``'objc'``). Will be detected | |
| | from the source extensions if | |
| | not provided. | |
+------------------------+--------------------------------+---------------------------+
| *optional* | specifies that a build failure | a boolean |
| | in the extension should not | |
| | abort the build process, but | |
| | simply skip the extension. | |
+------------------------+--------------------------------+---------------------------+
.. versionchanged:: 3.8
On Unix, C extensions are no longer linked to libpython except on
Android and Cygwin.
.. class:: Distribution
A :class:`Distribution` describes how to build, install and package up a Python
software package.
See the :func:`setup` function for a list of keyword arguments accepted by the
Distribution constructor. :func:`setup` creates a Distribution instance.
.. versionchanged:: 3.7
:class:`~distutils.core.Distribution` now warns if ``classifiers``,
``keywords`` and ``platforms`` fields are not specified as a list or
a string.
.. class:: Command
A :class:`Command` class (or rather, an instance of one of its subclasses)
implement a single distutils command.
:mod:`distutils.ccompiler` --- CCompiler base class
===================================================
.. module:: distutils.ccompiler
:synopsis: Abstract CCompiler class
This module provides the abstract base class for the :class:`CCompiler`
classes. A :class:`CCompiler` instance can be used for all the compile and
link steps needed to build a single project. Methods are provided to set
options for the compiler --- macro definitions, include directories, link path,
libraries and the like.
This module provides the following functions.
.. function:: gen_lib_options(compiler, library_dirs, runtime_library_dirs, libraries)
Generate linker options for searching library directories and linking with
specific libraries. *libraries* and *library_dirs* are, respectively, lists of
library names (not filenames!) and search directories. Returns a list of
command-line options suitable for use with some compiler (depending on the two
format strings passed in).
.. function:: gen_preprocess_options(macros, include_dirs)
Generate C pre-processor options (:option:`!-D`, :option:`!-U`, :option:`!-I`) as
used by at least two types of compilers: the typical Unix compiler and Visual
C++. *macros* is the usual thing, a list of 1- or 2-tuples, where ``(name,)``
means undefine (:option:`!-U`) macro *name*, and ``(name, value)`` means define
(:option:`!-D`) macro *name* to *value*. *include_dirs* is just a list of
directory names to be added to the header file search path (:option:`!-I`).
Returns a list of command-line options suitable for either Unix compilers or
Visual C++.
.. function:: get_default_compiler(osname, platform)
Determine the default compiler to use for the given platform.
*osname* should be one of the standard Python OS names (i.e. the ones returned
by ``os.name``) and *platform* the common value returned by ``sys.platform`` for
the platform in question.
The default values are ``os.name`` and ``sys.platform`` in case the parameters
are not given.
.. function:: new_compiler(plat=None, compiler=None, verbose=0, dry_run=0, force=0)
Factory function to generate an instance of some CCompiler subclass for the
supplied platform/compiler combination. *plat* defaults to ``os.name`` (eg.
``'posix'``, ``'nt'``), and *compiler* defaults to the default compiler for
that platform. Currently only ``'posix'`` and ``'nt'`` are supported, and the
default compilers are "traditional Unix interface" (:class:`UnixCCompiler`
class) and Visual C++ (:class:`MSVCCompiler` class). Note that it's perfectly
possible to ask for a Unix compiler object under Windows, and a Microsoft
compiler object under Unix---if you supply a value for *compiler*, *plat* is
ignored.
.. % Is the posix/nt only thing still true? Mac OS X seems to work, and
.. % returns a UnixCCompiler instance. How to document this... hmm.
.. function:: show_compilers()
Print list of available compilers (used by the :option:`!--help-compiler` options
to :command:`build`, :command:`build_ext`, :command:`build_clib`).
.. class:: CCompiler([verbose=0, dry_run=0, force=0])
The abstract base class :class:`CCompiler` defines the interface that must be
implemented by real compiler classes. The class also has some utility methods
used by several compiler classes.
The basic idea behind a compiler abstraction class is that each instance can be
used for all the compile/link steps in building a single project. Thus,
attributes common to all of those compile and link steps --- include
directories, macros to define, libraries to link against, etc. --- are
attributes of the compiler instance. To allow for variability in how individual
files are treated, most of those attributes may be varied on a per-compilation
or per-link basis.
The constructor for each subclass creates an instance of the Compiler object.
Flags are *verbose* (show verbose output), *dry_run* (don't actually execute the
steps) and *force* (rebuild everything, regardless of dependencies). All of
these flags default to ``0`` (off). Note that you probably don't want to
instantiate :class:`CCompiler` or one of its subclasses directly - use the
:func:`distutils.CCompiler.new_compiler` factory function instead.
The following methods allow you to manually alter compiler options for the
instance of the Compiler class.
.. method:: CCompiler.add_include_dir(dir)
Add *dir* to the list of directories that will be searched for header files.
The compiler is instructed to search directories in the order in which they are
supplied by successive calls to :meth:`add_include_dir`.
.. method:: CCompiler.set_include_dirs(dirs)
Set the list of directories that will be searched to *dirs* (a list of strings).
Overrides any preceding calls to :meth:`add_include_dir`; subsequent calls to
:meth:`add_include_dir` add to the list passed to :meth:`set_include_dirs`.
This does not affect any list of standard include directories that the compiler
may search by default.
.. method:: CCompiler.add_library(libname)
Add *libname* to the list of libraries that will be included in all links driven
by this compiler object. Note that *libname* should \*not\* be the name of a
file containing a library, but the name of the library itself: the actual
filename will be inferred by the linker, the compiler, or the compiler class
(depending on the platform).
The linker will be instructed to link against libraries in the order they were
supplied to :meth:`add_library` and/or :meth:`set_libraries`. It is perfectly
valid to duplicate library names; the linker will be instructed to link against
libraries as many times as they are mentioned.
.. method:: CCompiler.set_libraries(libnames)
Set the list of libraries to be included in all links driven by this compiler
object to *libnames* (a list of strings). This does not affect any standard
system libraries that the linker may include by default.
.. method:: CCompiler.add_library_dir(dir)
Add *dir* to the list of directories that will be searched for libraries
specified to :meth:`add_library` and :meth:`set_libraries`. The linker will be
instructed to search for libraries in the order they are supplied to
:meth:`add_library_dir` and/or :meth:`set_library_dirs`.
.. method:: CCompiler.set_library_dirs(dirs)
Set the list of library search directories to *dirs* (a list of strings). This
does not affect any standard library search path that the linker may search by
default.
.. method:: CCompiler.add_runtime_library_dir(dir)
Add *dir* to the list of directories that will be searched for shared libraries
at runtime.
.. method:: CCompiler.set_runtime_library_dirs(dirs)
Set the list of directories to search for shared libraries at runtime to *dirs*
(a list of strings). This does not affect any standard search path that the
runtime linker may search by default.
.. method:: CCompiler.define_macro(name[, value=None])
Define a preprocessor macro for all compilations driven by this compiler object.
The optional parameter *value* should be a string; if it is not supplied, then
the macro will be defined without an explicit value and the exact outcome
depends on the compiler used.
.. XXX true? does ANSI say anything about this?
.. method:: CCompiler.undefine_macro(name)
Undefine a preprocessor macro for all compilations driven by this compiler
object. If the same macro is defined by :meth:`define_macro` and
undefined by :meth:`undefine_macro` the last call takes precedence
(including multiple redefinitions or undefinitions). If the macro is
redefined/undefined on a per-compilation basis (ie. in the call to
:meth:`compile`), then that takes precedence.
.. method:: CCompiler.add_link_object(object)
Add *object* to the list of object files (or analogues, such as explicitly named
library files or the output of "resource compilers") to be included in every
link driven by this compiler object.
.. method:: CCompiler.set_link_objects(objects)
Set the list of object files (or analogues) to be included in every link to
*objects*. This does not affect any standard object files that the linker may
include by default (such as system libraries).
The following methods implement methods for autodetection of compiler options,
providing some functionality similar to GNU :program:`autoconf`.
.. method:: CCompiler.detect_language(sources)
Detect the language of a given file, or list of files. Uses the instance
attributes :attr:`~CCompiler.language_map` (a dictionary), and :attr:`~CCompiler.language_order` (a
list) to do the job.
.. method:: CCompiler.find_library_file(dirs, lib[, debug=0])
Search the specified list of directories for a static or shared library file
*lib* and return the full path to that file. If *debug* is true, look for a
debugging version (if that makes sense on the current platform). Return
``None`` if *lib* wasn't found in any of the specified directories.
.. method:: CCompiler.has_function(funcname [, includes=None, include_dirs=None, libraries=None, library_dirs=None])
Return a boolean indicating whether *funcname* is supported on the current
platform. The optional arguments can be used to augment the compilation
environment by providing additional include files and paths and libraries and
paths.
.. method:: CCompiler.library_dir_option(dir)
Return the compiler option to add *dir* to the list of directories searched for
libraries.
.. method:: CCompiler.library_option(lib)
Return the compiler option to add *lib* to the list of libraries linked into the
shared library or executable.
.. method:: CCompiler.runtime_library_dir_option(dir)
Return the compiler option to add *dir* to the list of directories searched for
runtime libraries.
.. method:: CCompiler.set_executables(**args)
Define the executables (and options for them) that will be run to perform the
various stages of compilation. The exact set of executables that may be
specified here depends on the compiler class (via the 'executables' class
attribute), but most will have:
+--------------+------------------------------------------+
| attribute | description |
+==============+==========================================+
| *compiler* | the C/C++ compiler |
+--------------+------------------------------------------+
| *linker_so* | linker used to create shared objects and |
| | libraries |
+--------------+------------------------------------------+
| *linker_exe* | linker used to create binary executables |
+--------------+------------------------------------------+
| *archiver* | static library creator |
+--------------+------------------------------------------+
On platforms with a command-line (Unix, DOS/Windows), each of these is a string
that will be split into executable name and (optional) list of arguments.
(Splitting the string is done similarly to how Unix shells operate: words are
delimited by spaces, but quotes and backslashes can override this. See
:func:`distutils.util.split_quoted`.)
The following methods invoke stages in the build process.
.. method:: CCompiler.compile(sources[, output_dir=None, macros=None, include_dirs=None, debug=0, extra_preargs=None, extra_postargs=None, depends=None])
Compile one or more source files. Generates object files (e.g. transforms a
:file:`.c` file to a :file:`.o` file.)
*sources* must be a list of filenames, most likely C/C++ files, but in reality
anything that can be handled by a particular compiler and compiler class (eg.
:class:`MSVCCompiler` can handle resource files in *sources*). Return a list of
object filenames, one per source filename in *sources*. Depending on the
implementation, not all source files will necessarily be compiled, but all
corresponding object filenames will be returned.
If *output_dir* is given, object files will be put under it, while retaining
their original path component. That is, :file:`foo/bar.c` normally compiles to
:file:`foo/bar.o` (for a Unix implementation); if *output_dir* is *build*, then
it would compile to :file:`build/foo/bar.o`.
*macros*, if given, must be a list of macro definitions. A macro definition is
either a ``(name, value)`` 2-tuple or a ``(name,)`` 1-tuple. The former defines
a macro; if the value is ``None``, the macro is defined without an explicit
value. The 1-tuple case undefines a macro. Later
definitions/redefinitions/undefinitions take precedence.
*include_dirs*, if given, must be a list of strings, the directories to add to
the default include file search path for this compilation only.
*debug* is a boolean; if true, the compiler will be instructed to output debug
symbols in (or alongside) the object file(s).
*extra_preargs* and *extra_postargs* are implementation-dependent. On platforms
that have the notion of a command-line (e.g. Unix, DOS/Windows), they are most
likely lists of strings: extra command-line arguments to prepend/append to the
compiler command line. On other platforms, consult the implementation class
documentation. In any event, they are intended as an escape hatch for those
occasions when the abstract compiler framework doesn't cut the mustard.
*depends*, if given, is a list of filenames that all targets depend on. If a
source file is older than any file in depends, then the source file will be
recompiled. This supports dependency tracking, but only at a coarse
granularity.
Raises :exc:`CompileError` on failure.
.. method:: CCompiler.create_static_lib(objects, output_libname[, output_dir=None, debug=0, target_lang=None])
Link a bunch of stuff together to create a static library file. The "bunch of
stuff" consists of the list of object files supplied as *objects*, the extra
object files supplied to :meth:`add_link_object` and/or
:meth:`set_link_objects`, the libraries supplied to :meth:`add_library` and/or
:meth:`set_libraries`, and the libraries supplied as *libraries* (if any).
*output_libname* should be a library name, not a filename; the filename will be
inferred from the library name. *output_dir* is the directory where the library
file will be put.
.. XXX defaults to what?
*debug* is a boolean; if true, debugging information will be included in the
library (note that on most platforms, it is the compile step where this matters:
the *debug* flag is included here just for consistency).
*target_lang* is the target language for which the given objects are being
compiled. This allows specific linkage time treatment of certain languages.
Raises :exc:`LibError` on failure.
.. method:: CCompiler.link(target_desc, objects, output_filename[, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None, target_lang=None])
Link a bunch of stuff together to create an executable or shared library file.
The "bunch of stuff" consists of the list of object files supplied as *objects*.
*output_filename* should be a filename. If *output_dir* is supplied,
*output_filename* is relative to it (i.e. *output_filename* can provide
directory components if needed).
*libraries* is a list of libraries to link against. These are library names,
not filenames, since they're translated into filenames in a platform-specific
way (eg. *foo* becomes :file:`libfoo.a` on Unix and :file:`foo.lib` on
DOS/Windows). However, they can include a directory component, which means the
linker will look in that specific directory rather than searching all the normal
locations.
*library_dirs*, if supplied, should be a list of directories to search for
libraries that were specified as bare library names (ie. no directory
component). These are on top of the system default and those supplied to
:meth:`add_library_dir` and/or :meth:`set_library_dirs`. *runtime_library_dirs*
is a list of directories that will be embedded into the shared library and used
to search for other shared libraries that \*it\* depends on at run-time. (This
may only be relevant on Unix.)
*export_symbols* is a list of symbols that the shared library will export.
(This appears to be relevant only on Windows.)
*debug* is as for :meth:`compile` and :meth:`create_static_lib`, with the
slight distinction that it actually matters on most platforms (as opposed to
:meth:`create_static_lib`, which includes a *debug* flag mostly for form's
sake).
*extra_preargs* and *extra_postargs* are as for :meth:`compile` (except of
course that they supply command-line arguments for the particular linker being
used).
*target_lang* is the target language for which the given objects are being
compiled. This allows specific linkage time treatment of certain languages.
Raises :exc:`LinkError` on failure.
.. method:: CCompiler.link_executable(objects, output_progname[, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, debug=0, extra_preargs=None, extra_postargs=None, target_lang=None])
Link an executable. *output_progname* is the name of the file executable, while
*objects* are a list of object filenames to link in. Other arguments are as for
the :meth:`link` method.
.. method:: CCompiler.link_shared_lib(objects, output_libname[, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None, target_lang=None])
Link a shared library. *output_libname* is the name of the output library,
while *objects* is a list of object filenames to link in. Other arguments are
as for the :meth:`link` method.
.. method:: CCompiler.link_shared_object(objects, output_filename[, output_dir=None, libraries=None, library_dirs=None, runtime_library_dirs=None, export_symbols=None, debug=0, extra_preargs=None, extra_postargs=None, build_temp=None, target_lang=None])
Link a shared object. *output_filename* is the name of the shared object that
will be created, while *objects* is a list of object filenames to link in.
Other arguments are as for the :meth:`link` method.
.. method:: CCompiler.preprocess(source[, output_file=None, macros=None, include_dirs=None, extra_preargs=None, extra_postargs=None])
Preprocess a single C/C++ source file, named in *source*. Output will be written
to file named *output_file*, or *stdout* if *output_file* not supplied.
*macros* is a list of macro definitions as for :meth:`compile`, which will
augment the macros set with :meth:`define_macro` and :meth:`undefine_macro`.
*include_dirs* is a list of directory names that will be added to the default
list, in the same way as :meth:`add_include_dir`.
Raises :exc:`PreprocessError` on failure.
The following utility methods are defined by the :class:`CCompiler` class, for
use by the various concrete subclasses.
.. method:: CCompiler.executable_filename(basename[, strip_dir=0, output_dir=''])
Returns the filename of the executable for the given *basename*. Typically for
non-Windows platforms this is the same as the basename, while Windows will get
a :file:`.exe` added.
.. method:: CCompiler.library_filename(libname[, lib_type='static', strip_dir=0, output_dir=''])
Returns the filename for the given library name on the current platform. On Unix
a library with *lib_type* of ``'static'`` will typically be of the form
:file:`liblibname.a`, while a *lib_type* of ``'dynamic'`` will be of the form
:file:`liblibname.so`.
.. method:: CCompiler.object_filenames(source_filenames[, strip_dir=0, output_dir=''])
Returns the name of the object files for the given source files.
*source_filenames* should be a list of filenames.
.. method:: CCompiler.shared_object_filename(basename[, strip_dir=0, output_dir=''])
Returns the name of a shared object file for the given file name *basename*.
.. method:: CCompiler.execute(func, args[, msg=None, level=1])
Invokes :func:`distutils.util.execute`. This method invokes a Python function
*func* with the given arguments *args*, after logging and taking into account
the *dry_run* flag.
.. method:: CCompiler.spawn(cmd)
Invokes :func:`distutils.spawn.spawn`. This invokes an external process to run
the given command.
.. method:: CCompiler.mkpath(name[, mode=511])
Invokes :func:`distutils.dir_util.mkpath`. This creates a directory and any
missing ancestor directories.
.. method:: CCompiler.move_file(src, dst)
Invokes :meth:`distutils.file_util.move_file`. Renames *src* to *dst*.
.. method:: CCompiler.announce(msg[, level=1])
Write a message using :func:`distutils.log.debug`.
.. method:: CCompiler.warn(msg)
Write a warning message *msg* to standard error.
.. method:: CCompiler.debug_print(msg)
If the *debug* flag is set on this :class:`CCompiler` instance, print *msg* to
standard output, otherwise do nothing.
.. % \subsection{Compiler-specific modules}
.. %
.. % The following modules implement concrete subclasses of the abstract
.. % \class{CCompiler} class. They should not be instantiated directly, but should
.. % be created using \function{distutils.ccompiler.new_compiler()} factory
.. % function.
:mod:`distutils.unixccompiler` --- Unix C Compiler
==================================================
.. module:: distutils.unixccompiler
:synopsis: UNIX C Compiler
This module provides the :class:`UnixCCompiler` class, a subclass of
:class:`CCompiler` that handles the typical Unix-style command-line C compiler:
* macros defined with :option:`!-Dname[=value]`
* macros undefined with :option:`!-Uname`
* include search directories specified with :option:`!-Idir`
* libraries specified with :option:`!-llib`
* library search directories specified with :option:`!-Ldir`
* compile handled by :program:`cc` (or similar) executable with :option:`!-c`
option: compiles :file:`.c` to :file:`.o`
* link static library handled by :program:`ar` command (possibly with
:program:`ranlib`)
* link shared library handled by :program:`cc` :option:`!-shared`
:mod:`distutils.msvccompiler` --- Microsoft Compiler
====================================================
.. module:: distutils.msvccompiler
:synopsis: Microsoft Compiler
.. XXX: This is *waaaaay* out of date!
This module provides :class:`MSVCCompiler`, an implementation of the abstract
:class:`CCompiler` class for Microsoft Visual Studio. Typically, extension
modules need to be compiled with the same compiler that was used to compile
Python. For Python 2.3 and earlier, the compiler was Visual Studio 6. For Python
2.4 and 2.5, the compiler is Visual Studio .NET 2003.
:class:`MSVCCompiler` will normally choose the right compiler, linker etc. on
its own. To override this choice, the environment variables *DISTUTILS_USE_SDK*
and *MSSdk* must be both set. *MSSdk* indicates that the current environment has
been setup by the SDK's ``SetEnv.Cmd`` script, or that the environment variables
had been registered when the SDK was installed; *DISTUTILS_USE_SDK* indicates
that the distutils user has made an explicit choice to override the compiler
selection by :class:`MSVCCompiler`.
:mod:`distutils.bcppcompiler` --- Borland Compiler
==================================================
.. module:: distutils.bcppcompiler
This module provides :class:`BorlandCCompiler`, a subclass of the abstract
:class:`CCompiler` class for the Borland C++ compiler.
:mod:`distutils.cygwinccompiler` --- Cygwin Compiler
====================================================
.. module:: distutils.cygwinccompiler
This module provides the :class:`CygwinCCompiler` class, a subclass of
:class:`UnixCCompiler` that handles the Cygwin port of the GNU C compiler to
Windows. It also contains the Mingw32CCompiler class which handles the mingw32
port of GCC (same as cygwin in no-cygwin mode).
:mod:`distutils.archive_util` --- Archiving utilities
======================================================
.. module:: distutils.archive_util
:synopsis: Utility functions for creating archive files (tarballs, zip files, ...)
This module provides a few functions for creating archive files, such as
tarballs or zipfiles.
.. function:: make_archive(base_name, format[, root_dir=None, base_dir=None, verbose=0, dry_run=0])
Create an archive file (eg. ``zip`` or ``tar``). *base_name* is the name of
the file to create, minus any format-specific extension; *format* is the
archive format: one of ``zip``, ``tar``, ``gztar``, ``bztar``, ``xztar``, or
``ztar``. *root_dir* is a directory that will be the root directory of the
archive; ie. we typically ``chdir`` into *root_dir* before creating the
archive. *base_dir* is the directory where we start archiving from; ie.
*base_dir* will be the common prefix of all files and directories in the
archive. *root_dir* and *base_dir* both default to the current directory.
Returns the name of the archive file.
.. versionchanged:: 3.5
Added support for the ``xztar`` format.
.. function:: make_tarball(base_name, base_dir[, compress='gzip', verbose=0, dry_run=0])
'Create an (optional compressed) archive as a tar file from all files in and
under *base_dir*. *compress* must be ``'gzip'`` (the default),
``'bzip2'``, ``'xz'``, ``'compress'``, or ``None``. For the ``'compress'``
method the compression utility named by :program:`compress` must be on the
default program search path, so this is probably Unix-specific. The output
tar file will be named :file:`base_dir.tar`, possibly plus the appropriate
compression extension (``.gz``, ``.bz2``, ``.xz`` or ``.Z``). Return the
output filename.
.. versionchanged:: 3.5
Added support for the ``xz`` compression.
.. function:: make_zipfile(base_name, base_dir[, verbose=0, dry_run=0])
Create a zip file from all files in and under *base_dir*. The output zip file
will be named *base_name* + :file:`.zip`. Uses either the :mod:`zipfile` Python
module (if available) or the InfoZIP :file:`zip` utility (if installed and
found on the default search path). If neither tool is available, raises
:exc:`DistutilsExecError`. Returns the name of the output zip file.
:mod:`distutils.dep_util` --- Dependency checking
=================================================
.. module:: distutils.dep_util
:synopsis: Utility functions for simple dependency checking
This module provides functions for performing simple, timestamp-based
dependency of files and groups of files; also, functions based entirely on such
timestamp dependency analysis.
.. function:: newer(source, target)
Return true if *source* exists and is more recently modified than *target*, or
if *source* exists and *target* doesn't. Return false if both exist and *target*
is the same age or newer than *source*. Raise :exc:`DistutilsFileError` if
*source* does not exist.
.. function:: newer_pairwise(sources, targets)
Walk two filename lists in parallel, testing if each source is newer than its
corresponding target. Return a pair of lists (*sources*, *targets*) where
source is newer than target, according to the semantics of :func:`newer`.
.. % % equivalent to a listcomp...
.. function:: newer_group(sources, target[, missing='error'])
Return true if *target* is out-of-date with respect to any file listed in
*sources*. In other words, if *target* exists and is newer than every file in
*sources*, return false; otherwise return true. *missing* controls what we do
when a source file is missing; the default (``'error'``) is to blow up with an
:exc:`OSError` from inside :func:`os.stat`; if it is ``'ignore'``, we silently
drop any missing source files; if it is ``'newer'``, any missing source files
make us assume that *target* is out-of-date (this is handy in "dry-run" mode:
it'll make you pretend to carry out commands that wouldn't work because inputs
are missing, but that doesn't matter because you're not actually going to run
the commands).
:mod:`distutils.dir_util` --- Directory tree operations
=======================================================
.. module:: distutils.dir_util
:synopsis: Utility functions for operating on directories and directory trees
This module provides functions for operating on directories and trees of
directories.
.. function:: mkpath(name[, mode=0o777, verbose=0, dry_run=0])
Create a directory and any missing ancestor directories. If the directory
already exists (or if *name* is the empty string, which means the current
directory, which of course exists), then do nothing. Raise
:exc:`DistutilsFileError` if unable to create some directory along the way (eg.
some sub-path exists, but is a file rather than a directory). If *verbose* is
true, print a one-line summary of each mkdir to stdout. Return the list of
directories actually created.
.. function:: create_tree(base_dir, files[, mode=0o777, verbose=0, dry_run=0])
Create all the empty directories under *base_dir* needed to put *files* there.
*base_dir* is just the name of a directory which doesn't necessarily exist
yet; *files* is a list of filenames to be interpreted relative to *base_dir*.
*base_dir* + the directory portion of every file in *files* will be created if
it doesn't already exist. *mode*, *verbose* and *dry_run* flags are as for
:func:`mkpath`.
.. function:: copy_tree(src, dst[, preserve_mode=1, preserve_times=1, preserve_symlinks=0, update=0, verbose=0, dry_run=0])
Copy an entire directory tree *src* to a new location *dst*. Both *src* and
*dst* must be directory names. If *src* is not a directory, raise
:exc:`DistutilsFileError`. If *dst* does not exist, it is created with
:func:`mkpath`. The end result of the copy is that every file in *src* is
copied to *dst*, and directories under *src* are recursively copied to *dst*.
Return the list of files that were copied or might have been copied, using their
output name. The return value is unaffected by *update* or *dry_run*: it is
simply the list of all files under *src*, with the names changed to be under
*dst*.
*preserve_mode* and *preserve_times* are the same as for
:func:`distutils.file_util.copy_file`; note that they only apply to
regular files, not to
directories. If *preserve_symlinks* is true, symlinks will be copied as
symlinks (on platforms that support them!); otherwise (the default), the
destination of the symlink will be copied. *update* and *verbose* are the same
as for :func:`~distutils.file_util.copy_file`.
Files in *src* that begin with :file:`.nfs` are skipped (more information on
these files is available in answer D2 of the `NFS FAQ page
`_).
.. versionchanged:: 3.3.1
NFS files are ignored.
.. function:: remove_tree(directory[, verbose=0, dry_run=0])
Recursively remove *directory* and all files and directories underneath it. Any
errors are ignored (apart from being reported to ``sys.stdout`` if *verbose* is
true).
:mod:`distutils.file_util` --- Single file operations
=====================================================
.. module:: distutils.file_util
:synopsis: Utility functions for operating on single files
This module contains some utility functions for operating on individual files.
.. function:: copy_file(src, dst[, preserve_mode=1, preserve_times=1, update=0, link=None, verbose=0, dry_run=0])
Copy file *src* to *dst*. If *dst* is a directory, then *src* is copied there
with the same name; otherwise, it must be a filename. (If the file exists, it
will be ruthlessly clobbered.) If *preserve_mode* is true (the default), the
file's mode (type and permission bits, or whatever is analogous on the
current platform) is copied. If *preserve_times* is true (the default), the
last-modified and last-access times are copied as well. If *update* is true,
*src* will only be copied if *dst* does not exist, or if *dst* does exist but
is older than *src*.
*link* allows you to make hard links (using :func:`os.link`) or symbolic links
(using :func:`os.symlink`) instead of copying: set it to ``'hard'`` or
``'sym'``; if it is ``None`` (the default), files are copied. Don't set *link*
on systems that don't support it: :func:`copy_file` doesn't check if hard or
symbolic linking is available. It uses :func:`~distutils.file_util._copy_file_contents` to copy file
contents.
Return a tuple ``(dest_name, copied)``: *dest_name* is the actual name of the
output file, and *copied* is true if the file was copied (or would have been
copied, if *dry_run* true).
.. % XXX if the destination file already exists, we clobber it if
.. % copying, but blow up if linking. Hmmm. And I don't know what
.. % macostools.copyfile() does. Should definitely be consistent, and
.. % should probably blow up if destination exists and we would be
.. % changing it (ie. it's not already a hard/soft link to src OR
.. % (not update) and (src newer than dst)).
.. function:: move_file(src, dst[, verbose, dry_run])
Move file *src* to *dst*. If *dst* is a directory, the file will be moved into
it with the same name; otherwise, *src* is just renamed to *dst*. Returns the
new full name of the file.
.. warning::
Handles cross-device moves on Unix using :func:`copy_file`. What about
other systems?
.. function:: write_file(filename, contents)
Create a file called *filename* and write *contents* (a sequence of strings
without line terminators) to it.
:mod:`distutils.util` --- Miscellaneous other utility functions
===============================================================
.. module:: distutils.util
:synopsis: Miscellaneous other utility functions
This module contains other assorted bits and pieces that don't fit into any
other utility module.
.. function:: get_platform()
Return a string that identifies the current platform. This is used mainly to
distinguish platform-specific build directories and platform-specific built
distributions. Typically includes the OS name and version and the
architecture (as supplied by 'os.uname()'), although the exact information
included depends on the OS; e.g., on Linux, the kernel version isn't
particularly important.
Examples of returned values:
* ``linux-i586``
* ``linux-alpha``
* ``solaris-2.6-sun4u``
For non-POSIX platforms, currently just returns ``sys.platform``.
For Mac OS X systems the OS version reflects the minimal version on which
binaries will run (that is, the value of ``MACOSX_DEPLOYMENT_TARGET``
during the build of Python), not the OS version of the current system.
For universal binary builds on Mac OS X the architecture value reflects
the universal binary status instead of the architecture of the current
processor. For 32-bit universal binaries the architecture is ``fat``,
for 64-bit universal binaries the architecture is ``fat64``, and
for 4-way universal binaries the architecture is ``universal``. Starting
from Python 2.7 and Python 3.2 the architecture ``fat3`` is used for
a 3-way universal build (ppc, i386, x86_64) and ``intel`` is used for
a universal build with the i386 and x86_64 architectures
Examples of returned values on Mac OS X:
* ``macosx-10.3-ppc``
* ``macosx-10.3-fat``
* ``macosx-10.5-universal``
* ``macosx-10.6-intel``
For AIX, Python 3.9 and later return a string starting with "aix", followed
by additional fields (separated by ``'-'``) that represent the combined
values of AIX Version, Release and Technology Level (first field), Build Date
(second field), and bit-size (third field). Python 3.8 and earlier returned
only a single additional field with the AIX Version and Release.
Examples of returned values on AIX:
* ``aix-5307-0747-32`` # 32-bit build on AIX ``oslevel -s``: 5300-07-00-0000
* ``aix-7105-1731-64`` # 64-bit build on AIX ``oslevel -s``: 7100-05-01-1731
* ``aix-7.2`` # Legacy form reported in Python 3.8 and earlier
.. versionchanged:: 3.9
The AIX platform string format now also includes the technology level,
build date, and ABI bit-size.
.. function:: convert_path(pathname)
Return 'pathname' as a name that will work on the native filesystem, i.e. split
it on '/' and put it back together again using the current directory separator.
Needed because filenames in the setup script are always supplied in Unix style,
and have to be converted to the local convention before we can actually use them
in the filesystem. Raises :exc:`ValueError` on non-Unix-ish systems if
*pathname* either starts or ends with a slash.
.. function:: change_root(new_root, pathname)
Return *pathname* with *new_root* prepended. If *pathname* is relative, this is
equivalent to ``os.path.join(new_root,pathname)`` Otherwise, it requires making
*pathname* relative and then joining the two, which is tricky on DOS/Windows.
.. function:: check_environ()
Ensure that 'os.environ' has all the environment variables we guarantee that
users can use in config files, command-line options, etc. Currently this
includes:
* :envvar:`HOME` - user's home directory (Unix only)
* :envvar:`PLAT` - description of the current platform, including hardware and
OS (see :func:`get_platform`)
.. function:: subst_vars(s, local_vars)
Perform shell/Perl-style variable substitution on *s*. Every occurrence of
``$`` followed by a name is considered a variable, and variable is substituted
by the value found in the *local_vars* dictionary, or in ``os.environ`` if it's
not in *local_vars*. *os.environ* is first checked/augmented to guarantee that
it contains certain values: see :func:`check_environ`. Raise :exc:`ValueError`
for any variables not found in either *local_vars* or ``os.environ``.
Note that this is not a fully-fledged string interpolation function. A valid
``$variable`` can consist only of upper and lower case letters, numbers and an
underscore. No { } or ( ) style quoting is available.
.. function:: split_quoted(s)
Split a string up according to Unix shell-like rules for quotes and backslashes.
In short: words are delimited by spaces, as long as those spaces are not escaped
by a backslash, or inside a quoted string. Single and double quotes are
equivalent, and the quote characters can be backslash-escaped. The backslash is
stripped from any two-character escape sequence, leaving only the escaped
character. The quote characters are stripped from any quoted string. Returns a
list of words.
.. % Should probably be moved into the standard library.
.. function:: execute(func, args[, msg=None, verbose=0, dry_run=0])
Perform some action that affects the outside world (for instance, writing to the
filesystem). Such actions are special because they are disabled by the
*dry_run* flag. This method takes care of all that bureaucracy for you; all
you have to do is supply the function to call and an argument tuple for it (to
embody the "external action" being performed), and an optional message to print.
.. function:: strtobool(val)
Convert a string representation of truth to true (1) or false (0).
True values are ``y``, ``yes``, ``t``, ``true``, ``on`` and ``1``; false values
are ``n``, ``no``, ``f``, ``false``, ``off`` and ``0``. Raises
:exc:`ValueError` if *val* is anything else.
.. function:: byte_compile(py_files[, optimize=0, force=0, prefix=None, base_dir=None, verbose=1, dry_run=0, direct=None])
Byte-compile a collection of Python source files to :file:`.pyc` files in a
:file:`__pycache__` subdirectory (see :pep:`3147` and :pep:`488`).
*py_files* is a list of files to compile; any files that don't end in
:file:`.py` are silently skipped. *optimize* must be one of the following:
* ``0`` - don't optimize
* ``1`` - normal optimization (like ``python -O``)
* ``2`` - extra optimization (like ``python -OO``)
If *force* is true, all files are recompiled regardless of timestamps.
The source filename encoded in each :term:`bytecode` file defaults to the filenames
listed in *py_files*; you can modify these with *prefix* and *basedir*.
*prefix* is a string that will be stripped off of each source filename, and
*base_dir* is a directory name that will be prepended (after *prefix* is
stripped). You can supply either or both (or neither) of *prefix* and
*base_dir*, as you wish.
If *dry_run* is true, doesn't actually do anything that would affect the
filesystem.
Byte-compilation is either done directly in this interpreter process with the
standard :mod:`py_compile` module, or indirectly by writing a temporary script
and executing it. Normally, you should let :func:`byte_compile` figure out to
use direct compilation or not (see the source for details). The *direct* flag
is used by the script generated in indirect mode; unless you know what you're
doing, leave it set to ``None``.
.. versionchanged:: 3.2.3
Create ``.pyc`` files with an :func:`import magic tag
` in their name, in a :file:`__pycache__` subdirectory
instead of files without tag in the current directory.
.. versionchanged:: 3.5
Create ``.pyc`` files according to :pep:`488`.
.. function:: rfc822_escape(header)
Return a version of *header* escaped for inclusion in an :rfc:`822` header, by
ensuring there are 8 spaces space after each newline. Note that it does no other
modification of the string.
.. % this _can_ be replaced
.. % \subsection{Distutils objects}
:mod:`distutils.dist` --- The Distribution class
================================================
.. module:: distutils.dist
:synopsis: Provides the Distribution class, which represents the module distribution being
built/installed/distributed
This module provides the :class:`~distutils.core.Distribution` class, which
represents the module distribution being built/installed/distributed.
:mod:`distutils.extension` --- The Extension class
==================================================
.. module:: distutils.extension
:synopsis: Provides the Extension class, used to describe C/C++ extension modules in setup
scripts
This module provides the :class:`~distutils.extension.Extension` class,
used to describe C/C++ extension modules in setup scripts.
.. % \subsection{Ungrouped modules}
.. % The following haven't been moved into a more appropriate section yet.
:mod:`distutils.debug` --- Distutils debug mode
===============================================
.. module:: distutils.debug
:synopsis: Provides the debug flag for distutils
This module provides the DEBUG flag.
:mod:`distutils.errors` --- Distutils exceptions
================================================
.. module:: distutils.errors
:synopsis: Provides standard distutils exceptions
Provides exceptions used by the Distutils modules. Note that Distutils modules
may raise standard exceptions; in particular, SystemExit is usually raised for
errors that are obviously the end-user's fault (eg. bad command-line arguments).
This module is safe to use in ``from ... import *`` mode; it only exports
symbols whose names start with ``Distutils`` and end with ``Error``.
:mod:`distutils.fancy_getopt` --- Wrapper around the standard getopt module
===========================================================================
.. module:: distutils.fancy_getopt
:synopsis: Additional getopt functionality
This module provides a wrapper around the standard :mod:`getopt` module that
provides the following additional features:
* short and long options are tied together
* options have help strings, so :func:`fancy_getopt` could potentially create a
complete usage summary
* options set attributes of a passed-in object
* boolean options can have "negative aliases" --- eg. if :option:`!--quiet` is
the "negative alias" of :option:`!--verbose`, then :option:`!--quiet` on the
command line sets *verbose* to false.
.. function:: fancy_getopt(options, negative_opt, object, args)
Wrapper function. *options* is a list of ``(long_option, short_option,
help_string)`` 3-tuples as described in the constructor for
:class:`FancyGetopt`. *negative_opt* should be a dictionary mapping option names
to option names, both the key and value should be in the *options* list.
*object* is an object which will be used to store values (see the :meth:`~FancyGetopt.getopt`
method of the :class:`FancyGetopt` class). *args* is the argument list. Will use
``sys.argv[1:]`` if you pass ``None`` as *args*.
.. function:: wrap_text(text, width)
Wraps *text* to less than *width* wide.
.. class:: FancyGetopt([option_table=None])
The option_table is a list of 3-tuples: ``(long_option, short_option,
help_string)``
If an option takes an argument, its *long_option* should have ``'='`` appended;
*short_option* should just be a single character, no ``':'`` in any case.
*short_option* should be ``None`` if a *long_option* doesn't have a
corresponding *short_option*. All option tuples must have long options.
The :class:`FancyGetopt` class provides the following methods:
.. method:: FancyGetopt.getopt([args=None, object=None])
Parse command-line options in args. Store as attributes on *object*.
If *args* is ``None`` or not supplied, uses ``sys.argv[1:]``. If *object* is
``None`` or not supplied, creates a new :class:`OptionDummy` instance, stores
option values there, and returns a tuple ``(args, object)``. If *object* is
supplied, it is modified in place and :func:`getopt` just returns *args*; in
both cases, the returned *args* is a modified copy of the passed-in *args* list,
which is left untouched.
.. % and args returned are?
.. method:: FancyGetopt.get_option_order()
Returns the list of ``(option, value)`` tuples processed by the previous run of
:meth:`getopt` Raises :exc:`RuntimeError` if :meth:`getopt` hasn't been called
yet.
.. method:: FancyGetopt.generate_help([header=None])
Generate help text (a list of strings, one per suggested line of output) from
the option table for this :class:`FancyGetopt` object.
If supplied, prints the supplied *header* at the top of the help.
:mod:`distutils.filelist` --- The FileList class
================================================
.. module:: distutils.filelist
:synopsis: The FileList class, used for poking about the file system and
building lists of files.
This module provides the :class:`FileList` class, used for poking about the
filesystem and building lists of files.
:mod:`distutils.log` --- Simple :pep:`282`-style logging
========================================================
.. module:: distutils.log
:synopsis: A simple logging mechanism, :pep:`282`-style
:mod:`distutils.spawn` --- Spawn a sub-process
==============================================
.. module:: distutils.spawn
:synopsis: Provides the spawn() function
This module provides the :func:`~distutils.spawn.spawn` function, a
front-end to various platform-specific functions for launching another
program in a sub-process.
Also provides :func:`~distutils.spawn.find_executable` to search the path for a given executable
name.
:mod:`distutils.sysconfig` --- System configuration information
===============================================================
.. module:: distutils.sysconfig
:synopsis: Low-level access to configuration information of the Python interpreter.
.. moduleauthor:: Fred L. Drake, Jr.
.. moduleauthor:: Greg Ward
.. sectionauthor:: Fred L. Drake, Jr.
The :mod:`distutils.sysconfig` module provides access to Python's low-level
configuration information. The specific configuration variables available
depend heavily on the platform and configuration. The specific variables depend
on the build process for the specific version of Python being run; the variables
are those found in the :file:`Makefile` and configuration header that are
installed with Python on Unix systems. The configuration header is called
:file:`pyconfig.h` for Python versions starting with 2.2, and :file:`config.h`
for earlier versions of Python.
Some additional functions are provided which perform some useful manipulations
for other parts of the :mod:`distutils` package.
.. data:: PREFIX
The result of ``os.path.normpath(sys.prefix)``.
.. data:: EXEC_PREFIX
The result of ``os.path.normpath(sys.exec_prefix)``.
.. function:: get_config_var(name)
Return the value of a single variable. This is equivalent to
``get_config_vars().get(name)``.
.. function:: get_config_vars(...)
Return a set of variable definitions. If there are no arguments, this returns a
dictionary mapping names of configuration variables to values. If arguments are
provided, they should be strings, and the return value will be a sequence giving
the associated values. If a given name does not have a corresponding value,
``None`` will be included for that variable.
.. function:: get_config_h_filename()
Return the full path name of the configuration header. For Unix, this will be
the header generated by the :program:`configure` script; for other platforms the
header will have been supplied directly by the Python source distribution. The
file is a platform-specific text file.
.. function:: get_makefile_filename()
Return the full path name of the :file:`Makefile` used to build Python. For
Unix, this will be a file generated by the :program:`configure` script; the
meaning for other platforms will vary. The file is a platform-specific text
file, if it exists. This function is only useful on POSIX platforms.
.. function:: get_python_inc([plat_specific[, prefix]])
Return the directory for either the general or platform-dependent C include
files. If *plat_specific* is true, the platform-dependent include directory is
returned; if false or omitted, the platform-independent directory is returned.
If *prefix* is given, it is used as either the prefix instead of
:const:`PREFIX`, or as the exec-prefix instead of :const:`EXEC_PREFIX` if
*plat_specific* is true.
.. function:: get_python_lib([plat_specific[, standard_lib[, prefix]]])
Return the directory for either the general or platform-dependent library
installation. If *plat_specific* is true, the platform-dependent include
directory is returned; if false or omitted, the platform-independent directory
is returned. If *prefix* is given, it is used as either the prefix instead of
:const:`PREFIX`, or as the exec-prefix instead of :const:`EXEC_PREFIX` if
*plat_specific* is true. If *standard_lib* is true, the directory for the
standard library is returned rather than the directory for the installation of
third-party extensions.
The following function is only intended for use within the :mod:`distutils`
package.
.. function:: customize_compiler(compiler)
Do any platform-specific customization of a
:class:`distutils.ccompiler.CCompiler` instance.
This function is only needed on Unix at this time, but should be called
consistently to support forward-compatibility. It inserts the information that
varies across Unix flavors and is stored in Python's :file:`Makefile`. This
information includes the selected compiler, compiler and linker options, and the
extension used by the linker for shared objects.
This function is even more special-purpose, and should only be used from
Python's own build procedures.
.. function:: set_python_build()
Inform the :mod:`distutils.sysconfig` module that it is being used as part of
the build process for Python. This changes a lot of relative locations for
files, allowing them to be located in the build area rather than in an installed
Python.
:mod:`distutils.text_file` --- The TextFile class
=================================================
.. module:: distutils.text_file
:synopsis: Provides the TextFile class, a simple interface to text files
This module provides the :class:`TextFile` class, which gives an interface to
text files that (optionally) takes care of stripping comments, ignoring blank
lines, and joining lines with backslashes.
.. class:: TextFile([filename=None, file=None, **options])
This class provides a file-like object that takes care of all the things you
commonly want to do when processing a text file that has some line-by-line
syntax: strip comments (as long as ``#`` is your comment character), skip blank
lines, join adjacent lines by escaping the newline (ie. backslash at end of
line), strip leading and/or trailing whitespace. All of these are optional and
independently controllable.
The class provides a :meth:`warn` method so you can generate warning messages
that report physical line number, even if the logical line in question spans
multiple physical lines. Also provides :meth:`unreadline` for implementing
line-at-a-time lookahead.
:class:`TextFile` instances are create with either *filename*, *file*, or both.
:exc:`RuntimeError` is raised if both are ``None``. *filename* should be a
string, and *file* a file object (or something that provides :meth:`readline`
and :meth:`close` methods). It is recommended that you supply at least
*filename*, so that :class:`TextFile` can include it in warning messages. If
*file* is not supplied, :class:`TextFile` creates its own using the
:func:`open` built-in function.
The options are all boolean, and affect the values returned by :meth:`readline`
.. tabularcolumns:: |l|L|l|
+------------------+--------------------------------+---------+
| option name | description | default |
+==================+================================+=========+
| *strip_comments* | strip from ``'#'`` to | true |
| | end-of-line, as well as any | |
| | whitespace leading up to the | |
| | ``'#'``\ ---unless it is | |
| | escaped by a backslash | |
+------------------+--------------------------------+---------+
| *lstrip_ws* | strip leading whitespace from | false |
| | each line before returning it | |
+------------------+--------------------------------+---------+
| *rstrip_ws* | strip trailing whitespace | true |
| | (including line terminator!) | |
| | from each line before | |
| | returning it. | |
+------------------+--------------------------------+---------+
| *skip_blanks* | skip lines that are empty | true |
| | \*after\* stripping comments | |
| | and whitespace. (If both | |
| | lstrip_ws and rstrip_ws are | |
| | false, then some lines may | |
| | consist of solely whitespace: | |
| | these will \*not\* be skipped, | |
| | even if *skip_blanks* is | |
| | true.) | |
+------------------+--------------------------------+---------+
| *join_lines* | if a backslash is the last | false |
| | non-newline character on a | |
| | line after stripping comments | |
| | and whitespace, join the | |
| | following line to it to form | |
| | one logical line; if N | |
| | consecutive lines end with a | |
| | backslash, then N+1 physical | |
| | lines will be joined to form | |
| | one logical line. | |
+------------------+--------------------------------+---------+
| *collapse_join* | strip leading whitespace from | false |
| | lines that are joined to their | |
| | predecessor; only matters if | |
| | ``(join_lines and not | |
| | lstrip_ws)`` | |
+------------------+--------------------------------+---------+
Note that since *rstrip_ws* can strip the trailing newline, the semantics of
:meth:`readline` must differ from those of the built-in file object's
:meth:`readline` method! In particular, :meth:`readline` returns ``None`` for
end-of-file: an empty string might just be a blank line (or an all-whitespace
line), if *rstrip_ws* is true but *skip_blanks* is not.
.. method:: TextFile.open(filename)
Open a new file *filename*. This overrides any *file* or *filename*
constructor arguments.
.. method:: TextFile.close()
Close the current file and forget everything we know about it (including the
filename and the current line number).
.. method:: TextFile.warn(msg[,line=None])
Print (to stderr) a warning message tied to the current logical line in the
current file. If the current logical line in the file spans multiple physical
lines, the warning refers to the whole range, such as ``"lines 3-5"``. If
*line* is supplied, it overrides the current line number; it may be a list or
tuple to indicate a range of physical lines, or an integer for a single
physical line.
.. method:: TextFile.readline()
Read and return a single logical line from the current file (or from an internal
buffer if lines have previously been "unread" with :meth:`unreadline`). If the
*join_lines* option is true, this may involve reading multiple physical lines
concatenated into a single string. Updates the current line number, so calling
:meth:`warn` after :meth:`readline` emits a warning about the physical line(s)
just read. Returns ``None`` on end-of-file, since the empty string can occur
if *rstrip_ws* is true but *strip_blanks* is not.
.. method:: TextFile.readlines()
Read and return the list of all logical lines remaining in the current file.
This updates the current line number to the last line of the file.
.. method:: TextFile.unreadline(line)
Push *line* (a string) onto an internal buffer that will be checked by future
:meth:`readline` calls. Handy for implementing a parser with line-at-a-time
lookahead. Note that lines that are "unread" with :meth:`unreadline` are not
subsequently re-cleansed (whitespace stripped, or whatever) when read with
:meth:`readline`. If multiple calls are made to :meth:`unreadline` before a call
to :meth:`readline`, the lines will be returned most in most recent first order.
:mod:`distutils.version` --- Version number classes
===================================================
.. module:: distutils.version
:synopsis: Implements classes that represent module version numbers.
.. % todo
.. % \section{Distutils Commands}
.. %
.. % This part of Distutils implements the various Distutils commands, such
.. % as \code{build}, \code{install} \&c. Each command is implemented as a
.. % separate module, with the command name as the name of the module.
:mod:`distutils.cmd` --- Abstract base class for Distutils commands
===================================================================
.. module:: distutils.cmd
:synopsis: Provides the abstract base class :class:`~distutils.cmd.Command`. This class
is subclassed by the modules in the distutils.command subpackage.
This module supplies the abstract base class :class:`Command`.
.. class:: Command(dist)
Abstract base class for defining command classes, the "worker bees" of the
Distutils. A useful analogy for command classes is to think of them as
subroutines with local variables called *options*. The options are declared
in :meth:`initialize_options` and defined (given their final values) in
:meth:`finalize_options`, both of which must be defined by every command
class. The distinction between the two is necessary because option values
might come from the outside world (command line, config file, ...), and any
options dependent on other options must be computed after these outside
influences have been processed --- hence :meth:`finalize_options`. The body
of the subroutine, where it does all its work based on the values of its
options, is the :meth:`run` method, which must also be implemented by every
command class.
The class constructor takes a single argument *dist*, a
:class:`~distutils.core.Distribution` instance.
Creating a new Distutils command
================================
This section outlines the steps to create a new Distutils command.
A new command lives in a module in the :mod:`distutils.command` package. There
is a sample template in that directory called :file:`command_template`. Copy
this file to a new module with the same name as the new command you're
implementing. This module should implement a class with the same name as the
module (and the command). So, for instance, to create the command
``peel_banana`` (so that users can run ``setup.py peel_banana``), you'd copy
:file:`command_template` to :file:`distutils/command/peel_banana.py`, then edit
it so that it's implementing the class ``peel_banana``, a subclass of
:class:`distutils.cmd.Command`.
Subclasses of :class:`Command` must define the following methods.
.. method:: Command.initialize_options()
Set default values for all the options that this command supports. Note that
these defaults may be overridden by other commands, by the setup script, by
config files, or by the command-line. Thus, this is not the place to code
dependencies between options; generally, :meth:`initialize_options`
implementations are just a bunch of ``self.foo = None`` assignments.
.. method:: Command.finalize_options()
Set final values for all the options that this command supports. This is
always called as late as possible, ie. after any option assignments from the
command-line or from other commands have been done. Thus, this is the place
to code option dependencies: if *foo* depends on *bar*, then it is safe to
set *foo* from *bar* as long as *foo* still has the same value it was
assigned in :meth:`initialize_options`.
.. method:: Command.run()
A command's raison d'etre: carry out the action it exists to perform, controlled
by the options initialized in :meth:`initialize_options`, customized by other
commands, the setup script, the command-line, and config files, and finalized in
:meth:`finalize_options`. All terminal output and filesystem interaction should
be done by :meth:`run`.
.. attribute:: Command.sub_commands
*sub_commands* formalizes the notion of a "family" of commands,
e.g. ``install`` as the parent with sub-commands ``install_lib``,
``install_headers``, etc. The parent of a family of commands defines
*sub_commands* as a class attribute; it's a list of 2-tuples ``(command_name,
predicate)``, with *command_name* a string and *predicate* a function, a
string or ``None``. *predicate* is a method of the parent command that
determines whether the corresponding command is applicable in the current
situation. (E.g. ``install_headers`` is only applicable if we have any C
header files to install.) If *predicate* is ``None``, that command is always
applicable.
*sub_commands* is usually defined at the *end* of a class, because
predicates can be methods of the class, so they must already have been
defined. The canonical example is the :command:`install` command.
:mod:`distutils.command` --- Individual Distutils commands
==========================================================
.. module:: distutils.command
:synopsis: Contains one module for each standard Distutils command.
.. % \subsubsection{Individual Distutils commands}
.. % todo
:mod:`distutils.command.bdist` --- Build a binary installer
===========================================================
.. module:: distutils.command.bdist
:synopsis: Build a binary installer for a package
.. % todo
:mod:`distutils.command.bdist_packager` --- Abstract base class for packagers
=============================================================================
.. module:: distutils.command.bdist_packager
:synopsis: Abstract base class for packagers
.. % todo
:mod:`distutils.command.bdist_dumb` --- Build a "dumb" installer
================================================================
.. module:: distutils.command.bdist_dumb
:synopsis: Build a "dumb" installer - a simple archive of files
:mod:`distutils.command.bdist_rpm` --- Build a binary distribution as a Redhat RPM and SRPM
===========================================================================================
.. module:: distutils.command.bdist_rpm
:synopsis: Build a binary distribution as a Redhat RPM and SRPM
.. % todo
:mod:`distutils.command.sdist` --- Build a source distribution
==============================================================
.. module:: distutils.command.sdist
:synopsis: Build a source distribution
.. % todo
:mod:`distutils.command.build` --- Build all files of a package
===============================================================
.. module:: distutils.command.build
:synopsis: Build all files of a package
.. % todo
:mod:`distutils.command.build_clib` --- Build any C libraries in a package
==========================================================================
.. module:: distutils.command.build_clib
:synopsis: Build any C libraries in a package
.. % todo
:mod:`distutils.command.build_ext` --- Build any extensions in a package
========================================================================
.. module:: distutils.command.build_ext
:synopsis: Build any extensions in a package
.. % todo
:mod:`distutils.command.build_py` --- Build the .py/.pyc files of a package
===========================================================================
.. module:: distutils.command.build_py
:synopsis: Build the .py/.pyc files of a package
.. class:: build_py
:mod:`distutils.command.build_scripts` --- Build the scripts of a package
=========================================================================
.. module:: distutils.command.build_scripts
:synopsis: Build the scripts of a package
.. % todo
:mod:`distutils.command.clean` --- Clean a package build area
=============================================================
.. module:: distutils.command.clean
:synopsis: Clean a package build area
This command removes the temporary files created by :command:`build`
and its subcommands, like intermediary compiled object files. With
the ``--all`` option, the complete build directory will be removed.
Extension modules built :ref:`in place `
will not be cleaned, as they are not in the build directory.
:mod:`distutils.command.config` --- Perform package configuration
=================================================================
.. module:: distutils.command.config
:synopsis: Perform package configuration
.. % todo
:mod:`distutils.command.install` --- Install a package
======================================================
.. module:: distutils.command.install
:synopsis: Install a package
.. % todo
:mod:`distutils.command.install_data` --- Install data files from a package
===========================================================================
.. module:: distutils.command.install_data
:synopsis: Install data files from a package
.. % todo
:mod:`distutils.command.install_headers` --- Install C/C++ header files from a package
======================================================================================
.. module:: distutils.command.install_headers
:synopsis: Install C/C++ header files from a package
.. % todo
:mod:`distutils.command.install_lib` --- Install library files from a package
=============================================================================
.. module:: distutils.command.install_lib
:synopsis: Install library files from a package
.. % todo
:mod:`distutils.command.install_scripts` --- Install script files from a package
================================================================================
.. module:: distutils.command.install_scripts
:synopsis: Install script files from a package
.. % todo
:mod:`distutils.command.register` --- Register a module with the Python Package Index
=====================================================================================
.. module:: distutils.command.register
:synopsis: Register a module with the Python Package Index
The ``register`` command registers the package with the Python Package Index.
This is described in more detail in :pep:`301`.
.. % todo
:mod:`distutils.command.check` --- Check the meta-data of a package
===================================================================
.. module:: distutils.command.check
:synopsis: Check the meta-data of a package
The ``check`` command performs some tests on the meta-data of a package.
For example, it verifies that all required meta-data are provided as
the arguments passed to the :func:`~distutils.core.setup` function.
.. % todo
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/builtdist.rst 0000644 0001751 0000173 00000045624 14467657412 023276 0 ustar 00runner docker .. _built-dist:
****************************
Creating Built Distributions
****************************
.. include:: ./_setuptools_disclaimer.rst
A "built distribution" is what you're probably used to thinking of either as a
"binary package" or an "installer" (depending on your background). It's not
necessarily binary, though, because it might contain only Python source code
and/or byte-code; and we don't call it a package, because that word is already
spoken for in Python. (And "installer" is a term specific to the world of
mainstream desktop systems.)
A built distribution is how you make life as easy as possible for installers of
your module distribution: for users of RPM-based Linux systems, it's a binary
RPM; for Windows users, it's an executable installer; for Debian-based Linux
users, it's a Debian package; and so forth. Obviously, no one person will be
able to create built distributions for every platform under the sun, so the
Distutils are designed to enable module developers to concentrate on their
specialty---writing code and creating source distributions---while an
intermediary species called *packagers* springs up to turn source distributions
into built distributions for as many platforms as there are packagers.
Of course, the module developer could be their own packager; or the packager could
be a volunteer "out there" somewhere who has access to a platform which the
original developer does not; or it could be software periodically grabbing new
source distributions and turning them into built distributions for as many
platforms as the software has access to. Regardless of who they are, a packager
uses the setup script and the :command:`bdist` command family to generate built
distributions.
As a simple example, if I run the following command in the Distutils source
tree::
python setup.py bdist
then the Distutils builds my module distribution (the Distutils itself in this
case), does a "fake" installation (also in the :file:`build` directory), and
creates the default type of built distribution for my platform. The default
format for built distributions is a "dumb" tar file on Unix, and a simple
executable installer on Windows. (That tar file is considered "dumb" because it
has to be unpacked in a specific location to work.)
Thus, the above command on a Unix system creates
:file:`Distutils-1.0.{plat}.tar.gz`; unpacking this tarball from the right place
installs the Distutils just as though you had downloaded the source distribution
and run ``python setup.py install``. (The "right place" is either the root of
the filesystem or Python's :file:`{prefix}` directory, depending on the options
given to the :command:`bdist_dumb` command; the default is to make dumb
distributions relative to :file:`{prefix}`.)
Obviously, for pure Python distributions, this isn't any simpler than just
running ``python setup.py install``\ ---but for non-pure distributions, which
include extensions that would need to be compiled, it can mean the difference
between someone being able to use your extensions or not. And creating "smart"
built distributions, such as an RPM package or an executable installer for
Windows, is far more convenient for users even if your distribution doesn't
include any extensions.
The :command:`bdist` command has a :option:`!--formats` option, similar to the
:command:`sdist` command, which you can use to select the types of built
distribution to generate: for example, ::
python setup.py bdist --format=zip
would, when run on a Unix system, create
:file:`Distutils-1.0.{plat}.zip`\ ---again, this archive would be unpacked
from the root directory to install the Distutils.
The available formats for built distributions are:
+-------------+------------------------------+---------+
| Format | Description | Notes |
+=============+==============================+=========+
| ``gztar`` | gzipped tar file | \(1) |
| | (:file:`.tar.gz`) | |
+-------------+------------------------------+---------+
| ``bztar`` | bzipped tar file | |
| | (:file:`.tar.bz2`) | |
+-------------+------------------------------+---------+
| ``xztar`` | xzipped tar file | |
| | (:file:`.tar.xz`) | |
+-------------+------------------------------+---------+
| ``ztar`` | compressed tar file | \(3) |
| | (:file:`.tar.Z`) | |
+-------------+------------------------------+---------+
| ``tar`` | tar file (:file:`.tar`) | |
+-------------+------------------------------+---------+
| ``zip`` | zip file (:file:`.zip`) | (2),(4) |
+-------------+------------------------------+---------+
| ``rpm`` | RPM | \(5) |
+-------------+------------------------------+---------+
| ``pkgtool`` | Solaris :program:`pkgtool` | |
+-------------+------------------------------+---------+
| ``sdux`` | HP-UX :program:`swinstall` | |
+-------------+------------------------------+---------+
.. versionchanged:: 3.5
Added support for the ``xztar`` format.
Notes:
(1)
default on Unix
(2)
default on Windows
(3)
requires external :program:`compress` utility.
(4)
requires either external :program:`zip` utility or :mod:`zipfile` module (part
of the standard Python library since Python 1.6)
(5)
requires external :program:`rpm` utility, version 3.0.4 or better (use ``rpm
--version`` to find out which version you have)
You don't have to use the :command:`bdist` command with the :option:`!--formats`
option; you can also use the command that directly implements the format you're
interested in. Some of these :command:`bdist` "sub-commands" actually generate
several similar formats; for instance, the :command:`bdist_dumb` command
generates all the "dumb" archive formats (``tar``, ``gztar``, ``bztar``,
``xztar``, ``ztar``, and ``zip``), and :command:`bdist_rpm` generates both
binary and source RPMs. The :command:`bdist` sub-commands, and the formats
generated by each, are:
+--------------------------+-------------------------------------+
| Command | Formats |
+==========================+=====================================+
| :command:`bdist_dumb` | tar, gztar, bztar, xztar, ztar, zip |
+--------------------------+-------------------------------------+
| :command:`bdist_rpm` | rpm, srpm |
+--------------------------+-------------------------------------+
The following sections give details on the individual :command:`bdist_\*`
commands.
.. .. _creating-dumb:
.. Creating dumb built distributions
.. =================================
.. XXX Need to document absolute vs. prefix-relative packages here, but first
I have to implement it!
.. _creating-rpms:
Creating RPM packages
=====================
The RPM format is used by many popular Linux distributions, including Red Hat,
SuSE, and Mandrake. If one of these (or any of the other RPM-based Linux
distributions) is your usual environment, creating RPM packages for other users
of that same distribution is trivial. Depending on the complexity of your module
distribution and differences between Linux distributions, you may also be able
to create RPMs that work on different RPM-based distributions.
The usual way to create an RPM of your module distribution is to run the
:command:`bdist_rpm` command::
python setup.py bdist_rpm
or the :command:`bdist` command with the :option:`!--format` option::
python setup.py bdist --formats=rpm
The former allows you to specify RPM-specific options; the latter allows you to
easily specify multiple formats in one run. If you need to do both, you can
explicitly specify multiple :command:`bdist_\*` commands and their options::
python setup.py bdist_rpm --packager="John Doe " \
bdist_dumb --dumb-option=foo
Creating RPM packages is driven by a :file:`.spec` file, much as using the
Distutils is driven by the setup script. To make your life easier, the
:command:`bdist_rpm` command normally creates a :file:`.spec` file based on the
information you supply in the setup script, on the command line, and in any
Distutils configuration files. Various options and sections in the
:file:`.spec` file are derived from options in the setup script as follows:
+------------------------------------------+----------------------------------------------+
| RPM :file:`.spec` file option or section | Distutils setup script option |
+==========================================+==============================================+
| Name | ``name`` |
+------------------------------------------+----------------------------------------------+
| Summary (in preamble) | ``description`` |
+------------------------------------------+----------------------------------------------+
| Version | ``version`` |
+------------------------------------------+----------------------------------------------+
| Vendor | ``author`` and ``author_email``, |
| | or --- & ``maintainer`` and |
| | ``maintainer_email`` |
+------------------------------------------+----------------------------------------------+
| Copyright | ``license`` |
+------------------------------------------+----------------------------------------------+
| Url | ``url`` |
+------------------------------------------+----------------------------------------------+
| %description (section) | ``long_description`` |
+------------------------------------------+----------------------------------------------+
Additionally, there are many options in :file:`.spec` files that don't have
corresponding options in the setup script. Most of these are handled through
options to the :command:`bdist_rpm` command as follows:
+-------------------------------+-----------------------------+-------------------------+
| RPM :file:`.spec` file option | :command:`bdist_rpm` option | default value |
| or section | | |
+===============================+=============================+=========================+
| Release | ``release`` | "1" |
+-------------------------------+-----------------------------+-------------------------+
| Group | ``group`` | "Development/Libraries" |
+-------------------------------+-----------------------------+-------------------------+
| Vendor | ``vendor`` | (see above) |
+-------------------------------+-----------------------------+-------------------------+
| Packager | ``packager`` | (none) |
+-------------------------------+-----------------------------+-------------------------+
| Provides | ``provides`` | (none) |
+-------------------------------+-----------------------------+-------------------------+
| Requires | ``requires`` | (none) |
+-------------------------------+-----------------------------+-------------------------+
| Conflicts | ``conflicts`` | (none) |
+-------------------------------+-----------------------------+-------------------------+
| Obsoletes | ``obsoletes`` | (none) |
+-------------------------------+-----------------------------+-------------------------+
| Distribution | ``distribution_name`` | (none) |
+-------------------------------+-----------------------------+-------------------------+
| BuildRequires | ``build_requires`` | (none) |
+-------------------------------+-----------------------------+-------------------------+
| Icon | ``icon`` | (none) |
+-------------------------------+-----------------------------+-------------------------+
Obviously, supplying even a few of these options on the command-line would be
tedious and error-prone, so it's usually best to put them in the setup
configuration file, :file:`setup.cfg`\ ---see section :ref:`setup-config`. If
you distribute or package many Python module distributions, you might want to
put options that apply to all of them in your personal Distutils configuration
file (:file:`~/.pydistutils.cfg`). If you want to temporarily disable
this file, you can pass the :option:`!--no-user-cfg` option to :file:`setup.py`.
There are three steps to building a binary RPM package, all of which are
handled automatically by the Distutils:
#. create a :file:`.spec` file, which describes the package (analogous to the
Distutils setup script; in fact, much of the information in the setup script
winds up in the :file:`.spec` file)
#. create the source RPM
#. create the "binary" RPM (which may or may not contain binary code, depending
on whether your module distribution contains Python extensions)
Normally, RPM bundles the last two steps together; when you use the Distutils,
all three steps are typically bundled together.
If you wish, you can separate these three steps. You can use the
:option:`!--spec-only` option to make :command:`bdist_rpm` just create the
:file:`.spec` file and exit; in this case, the :file:`.spec` file will be
written to the "distribution directory"---normally :file:`dist/`, but
customizable with the :option:`!--dist-dir` option. (Normally, the :file:`.spec`
file winds up deep in the "build tree," in a temporary directory created by
:command:`bdist_rpm`.)
.. % \XXX{this isn't implemented yet---is it needed?!}
.. % You can also specify a custom \file{.spec} file with the
.. % \longprogramopt{spec-file} option; used in conjunction with
.. % \longprogramopt{spec-only}, this gives you an opportunity to customize
.. % the \file{.spec} file manually:
.. %
.. % \ begin{verbatim}
.. % > python setup.py bdist_rpm --spec-only
.. % # ...edit dist/FooBar-1.0.spec
.. % > python setup.py bdist_rpm --spec-file=dist/FooBar-1.0.spec
.. % \ end{verbatim}
.. %
.. % (Although a better way to do this is probably to override the standard
.. % \command{bdist\_rpm} command with one that writes whatever else you want
.. % to the \file{.spec} file.)
.. _cross-compile-windows:
Cross-compiling on Windows
==========================
Starting with Python 2.6, distutils is capable of cross-compiling between
Windows platforms. In practice, this means that with the correct tools
installed, you can use a 32bit version of Windows to create 64bit extensions
and vice-versa.
To build for an alternate platform, specify the :option:`!--plat-name` option
to the build command. Valid values are currently 'win32', and 'win-amd64'.
For example, on a 32bit version of Windows, you could execute::
python setup.py build --plat-name=win-amd64
to build a 64bit version of your extension.
To cross-compile, you must download the Python source code and cross-compile
Python itself for the platform you are targeting - it is not possible from a
binary installation of Python (as the .lib etc file for other platforms are
not included.) In practice, this means the user of a 32 bit operating
system will need to use Visual Studio 2008 to open the
:file:`PCbuild/PCbuild.sln` solution in the Python source tree and build the
"x64" configuration of the 'pythoncore' project before cross-compiling
extensions is possible.
Note that by default, Visual Studio 2008 does not install 64bit compilers or
tools. You may need to reexecute the Visual Studio setup process and select
these tools (using Control Panel->[Add/Remove] Programs is a convenient way to
check or modify your existing install.)
.. _postinstallation-script:
The Postinstallation script
---------------------------
Starting with Python 2.3, a postinstallation script can be specified with the
:option:`!--install-script` option. The basename of the script must be
specified, and the script filename must also be listed in the scripts argument
to the setup function.
This script will be run at installation time on the target system after all the
files have been copied, with ``argv[1]`` set to :option:`!-install`, and again at
uninstallation time before the files are removed with ``argv[1]`` set to
:option:`!-remove`.
The installation script runs embedded in the windows installer, every output
(``sys.stdout``, ``sys.stderr``) is redirected into a buffer and will be
displayed in the GUI after the script has finished.
Some functions especially useful in this context are available as additional
built-in functions in the installation script.
.. function:: directory_created(path)
file_created(path)
These functions should be called when a directory or file is created by the
postinstall script at installation time. It will register *path* with the
uninstaller, so that it will be removed when the distribution is uninstalled.
To be safe, directories are only removed if they are empty.
.. function:: get_special_folder_path(csidl_string)
This function can be used to retrieve special folder locations on Windows like
the Start Menu or the Desktop. It returns the full path to the folder.
*csidl_string* must be one of the following strings::
"CSIDL_APPDATA"
"CSIDL_COMMON_STARTMENU"
"CSIDL_STARTMENU"
"CSIDL_COMMON_DESKTOPDIRECTORY"
"CSIDL_DESKTOPDIRECTORY"
"CSIDL_COMMON_STARTUP"
"CSIDL_STARTUP"
"CSIDL_COMMON_PROGRAMS"
"CSIDL_PROGRAMS"
"CSIDL_FONTS"
If the folder cannot be retrieved, :exc:`OSError` is raised.
Which folders are available depends on the exact Windows version, and probably
also the configuration. For details refer to Microsoft's documentation of the
:c:func:`SHGetSpecialFolderPath` function.
.. function:: create_shortcut(target, description, filename[, arguments[, workdir[, iconpath[, iconindex]]]])
This function creates a shortcut. *target* is the path to the program to be
started by the shortcut. *description* is the description of the shortcut.
*filename* is the title of the shortcut that the user will see. *arguments*
specifies the command line arguments, if any. *workdir* is the working directory
for the program. *iconpath* is the file containing the icon for the shortcut,
and *iconindex* is the index of the icon in the file *iconpath*. Again, for
details consult the Microsoft documentation for the :class:`IShellLink`
interface.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/commandref.rst 0000644 0001751 0000173 00000010750 14467657412 023376 0 ustar 00runner docker .. _reference:
*****************
Command Reference
*****************
.. include:: ./_setuptools_disclaimer.rst
.. % \section{Building modules: the \protect\command{build} command family}
.. % \label{build-cmds}
.. % \subsubsection{\protect\command{build}}
.. % \label{build-cmd}
.. % \subsubsection{\protect\command{build\_py}}
.. % \label{build-py-cmd}
.. % \subsubsection{\protect\command{build\_ext}}
.. % \label{build-ext-cmd}
.. % \subsubsection{\protect\command{build\_clib}}
.. % \label{build-clib-cmd}
.. _install-cmd:
Installing modules: the :command:`install` command family
=========================================================
The install command ensures that the build commands have been run and then runs
the subcommands :command:`install_lib`, :command:`install_data` and
:command:`install_scripts`.
.. % \subsubsection{\protect\command{install\_lib}}
.. % \label{install-lib-cmd}
.. _install-data-cmd:
:command:`install_data`
-----------------------
This command installs all data files provided with the distribution.
.. _install-scripts-cmd:
:command:`install_scripts`
--------------------------
This command installs all (Python) scripts in the distribution.
.. % \subsection{Cleaning up: the \protect\command{clean} command}
.. % \label{clean-cmd}
.. _sdist-cmd:
Creating a source distribution: the :command:`sdist` command
============================================================
.. XXX fragment moved down from above: needs context!
The manifest template commands are:
+-------------------------------------------+-----------------------------------------------+
| Command | Description |
+===========================================+===============================================+
| :command:`include pat1 pat2 ...` | include all files matching any of the listed |
| | patterns |
+-------------------------------------------+-----------------------------------------------+
| :command:`exclude pat1 pat2 ...` | exclude all files matching any of the listed |
| | patterns |
+-------------------------------------------+-----------------------------------------------+
| :command:`recursive-include dir pat1 pat2 | include all files under *dir* matching any of |
| ...` | the listed patterns |
+-------------------------------------------+-----------------------------------------------+
| :command:`recursive-exclude dir pat1 pat2 | exclude all files under *dir* matching any of |
| ...` | the listed patterns |
+-------------------------------------------+-----------------------------------------------+
| :command:`global-include pat1 pat2 ...` | include all files anywhere in the source tree |
| | matching --- & any of the listed patterns |
+-------------------------------------------+-----------------------------------------------+
| :command:`global-exclude pat1 pat2 ...` | exclude all files anywhere in the source tree |
| | matching --- & any of the listed patterns |
+-------------------------------------------+-----------------------------------------------+
| :command:`prune dir` | exclude all files under *dir* |
+-------------------------------------------+-----------------------------------------------+
| :command:`graft dir` | include all files under *dir* |
+-------------------------------------------+-----------------------------------------------+
The patterns here are Unix-style "glob" patterns: ``*`` matches any sequence of
regular filename characters, ``?`` matches any single regular filename
character, and ``[range]`` matches any of the characters in *range* (e.g.,
``a-z``, ``a-zA-Z``, ``a-f0-9_.``). The definition of "regular filename
character" is platform-specific: on Unix it is anything except slash; on Windows
anything except backslash or colon.
.. XXX Windows support not there yet
.. % \section{Creating a built distribution: the
.. % \protect\command{bdist} command family}
.. % \label{bdist-cmds}
.. % \subsection{\protect\command{bdist}}
.. % \subsection{\protect\command{bdist\_dumb}}
.. % \subsection{\protect\command{bdist\_rpm}}
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/configfile.rst 0000644 0001751 0000173 00000013756 14467657412 023401 0 ustar 00runner docker .. _setup-config:
************************************
Writing the Setup Configuration File
************************************
.. include:: ./_setuptools_disclaimer.rst
Often, it's not possible to write down everything needed to build a distribution
*a priori*: you may need to get some information from the user, or from the
user's system, in order to proceed. As long as that information is fairly
simple---a list of directories to search for C header files or libraries, for
example---then providing a configuration file, :file:`setup.cfg`, for users to
edit is a cheap and easy way to solicit it. Configuration files also let you
provide default values for any command option, which the installer can then
override either on the command-line or by editing the config file.
The setup configuration file is a useful middle-ground between the setup
script---which, ideally, would be opaque to installers [#]_---and the command-line to
the setup script, which is outside of your control and entirely up to the
installer. In fact, :file:`setup.cfg` (and any other Distutils configuration
files present on the target system) are processed after the contents of the
setup script, but before the command-line. This has several useful
consequences:
.. % (If you have more advanced needs, such as determining which extensions
.. % to build based on what capabilities are present on the target system,
.. % then you need the Distutils ``auto-configuration'' facility. This
.. % started to appear in Distutils 0.9 but, as of this writing, isn't mature
.. % or stable enough yet for real-world use.)
* installers can override some of what you put in :file:`setup.py` by editing
:file:`setup.cfg`
* you can provide non-standard defaults for options that are not easily set in
:file:`setup.py`
* installers can override anything in :file:`setup.cfg` using the command-line
options to :file:`setup.py` or by pointing :envvar:`DIST_EXTRA_CONFIG`
to another configuration file
The basic syntax of the configuration file is simple:
.. code-block:: ini
[command]
option=value
...
where *command* is one of the Distutils commands (e.g. :command:`build_py`,
:command:`install`), and *option* is one of the options that command supports.
Any number of options can be supplied for each command, and any number of
command sections can be included in the file. Blank lines are ignored, as are
comments, which run from a ``'#'`` character until the end of the line. Long
option values can be split across multiple lines simply by indenting the
continuation lines.
You can find out the list of options supported by a particular command with the
universal :option:`!--help` option, e.g.
.. code-block:: shell-session
$ python setup.py --help build_ext
[...]
Options for 'build_ext' command:
--build-lib (-b) directory for compiled extension modules
--build-temp (-t) directory for temporary files (build by-products)
--inplace (-i) ignore build-lib and put compiled extensions into the
source directory alongside your pure Python modules
--include-dirs (-I) list of directories to search for header files
--define (-D) C preprocessor macros to define
--undef (-U) C preprocessor macros to undefine
--swig-opts list of SWIG command line options
[...]
Note that an option spelled :option:`!--foo-bar` on the command-line is spelled
``foo_bar`` in configuration files.
.. _distutils-build-ext-inplace:
For example, say you want your extensions to be built "in-place"---that is, you
have an extension ``pkg.ext``, and you want the compiled extension file
(:file:`ext.so` on Unix, say) to be put in the same source directory as your
pure Python modules ``pkg.mod1`` and ``pkg.mod2``. You can always use the
:option:`!--inplace` option on the command-line to ensure this:
.. code-block:: sh
python setup.py build_ext --inplace
But this requires that you always specify the :command:`build_ext` command
explicitly, and remember to provide :option:`!--inplace`. An easier way is to
"set and forget" this option, by encoding it in :file:`setup.cfg`, the
configuration file for this distribution:
.. code-block:: ini
[build_ext]
inplace=1
This will affect all builds of this module distribution, whether or not you
explicitly specify :command:`build_ext`. If you include :file:`setup.cfg` in
your source distribution, it will also affect end-user builds---which is
probably a bad idea for this option, since always building extensions in-place
would break installation of the module distribution. In certain peculiar cases,
though, modules are built right in their installation directory, so this is
conceivably a useful ability. (Distributing extensions that expect to be built
in their installation directory is almost always a bad idea, though.)
Another example: certain commands take a lot of options that don't change from
run to run; for example, :command:`bdist_rpm` needs to know everything required
to generate a "spec" file for creating an RPM distribution. Some of this
information comes from the setup script, and some is automatically generated by
the Distutils (such as the list of files installed). But some of it has to be
supplied as options to :command:`bdist_rpm`, which would be very tedious to do
on the command-line for every run. Hence, here is a snippet from the Distutils'
own :file:`setup.cfg`:
.. code-block:: ini
[bdist_rpm]
release = 1
packager = Greg Ward
doc_files = CHANGES.txt
README.txt
USAGE.txt
doc/
examples/
Note that the ``doc_files`` option is simply a whitespace-separated string
split across multiple lines for readability.
.. seealso::
:ref:`inst-config-syntax` in "Installing Python Modules"
More information on the configuration files is available in the manual for
system administrators.
.. rubric:: Footnotes
.. [#] This ideal probably won't be achieved until auto-configuration is fully
supported by the Distutils.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/examples.rst 0000644 0001751 0000173 00000024016 14467657412 023101 0 ustar 00runner docker .. _distutils_examples:
******************
Distutils Examples
******************
.. include:: ./_setuptools_disclaimer.rst
This chapter provides a number of basic examples to help get started with
distutils. Additional information about using distutils can be found in the
Distutils Cookbook.
.. seealso::
`Distutils Cookbook `_
Collection of recipes showing how to achieve more control over distutils.
.. _pure-mod:
Pure Python distribution (by module)
====================================
If you're just distributing a couple of modules, especially if they don't live
in a particular package, you can specify them individually using the
``py_modules`` option in the setup script.
In the simplest case, you'll have two files to worry about: a setup script and
the single module you're distributing, :file:`foo.py` in this example::
/
setup.py
foo.py
(In all diagrams in this section, ** will refer to the distribution root
directory.) A minimal setup script to describe this situation would be::
from distutils.core import setup
setup(name='foo',
version='1.0',
py_modules=['foo'],
)
Note that the name of the distribution is specified independently with the
``name`` option, and there's no rule that says it has to be the same as
the name of the sole module in the distribution (although that's probably a good
convention to follow). However, the distribution name is used to generate
filenames, so you should stick to letters, digits, underscores, and hyphens.
Since ``py_modules`` is a list, you can of course specify multiple
modules, eg. if you're distributing modules ``foo`` and ``bar``, your
setup might look like this::
/
setup.py
foo.py
bar.py
and the setup script might be ::
from distutils.core import setup
setup(name='foobar',
version='1.0',
py_modules=['foo', 'bar'],
)
You can put module source files into another directory, but if you have enough
modules to do that, it's probably easier to specify modules by package rather
than listing them individually.
.. _pure-pkg:
Pure Python distribution (by package)
=====================================
If you have more than a couple of modules to distribute, especially if they are
in multiple packages, it's probably easier to specify whole packages rather than
individual modules. This works even if your modules are not in a package; you
can just tell the Distutils to process modules from the root package, and that
works the same as any other package (except that you don't have to have an
:file:`__init__.py` file).
The setup script from the last example could also be written as ::
from distutils.core import setup
setup(name='foobar',
version='1.0',
packages=[''],
)
(The empty string stands for the root package.)
If those two files are moved into a subdirectory, but remain in the root
package, e.g.::
/
setup.py
src/ foo.py
bar.py
then you would still specify the root package, but you have to tell the
Distutils where source files in the root package live::
from distutils.core import setup
setup(name='foobar',
version='1.0',
package_dir={'': 'src'},
packages=[''],
)
More typically, though, you will want to distribute multiple modules in the same
package (or in sub-packages). For example, if the ``foo`` and ``bar``
modules belong in package ``foobar``, one way to layout your source tree is
::
/
setup.py
foobar/
__init__.py
foo.py
bar.py
This is in fact the default layout expected by the Distutils, and the one that
requires the least work to describe in your setup script::
from distutils.core import setup
setup(name='foobar',
version='1.0',
packages=['foobar'],
)
If you want to put modules in directories not named for their package, then you
need to use the ``package_dir`` option again. For example, if the
:file:`src` directory holds modules in the ``foobar`` package::
/
setup.py
src/
__init__.py
foo.py
bar.py
an appropriate setup script would be ::
from distutils.core import setup
setup(name='foobar',
version='1.0',
package_dir={'foobar': 'src'},
packages=['foobar'],
)
Or, you might put modules from your main package right in the distribution
root::
/
setup.py
__init__.py
foo.py
bar.py
in which case your setup script would be ::
from distutils.core import setup
setup(name='foobar',
version='1.0',
package_dir={'foobar': ''},
packages=['foobar'],
)
(The empty string also stands for the current directory.)
If you have sub-packages, they must be explicitly listed in ``packages``,
but any entries in ``package_dir`` automatically extend to sub-packages.
(In other words, the Distutils does *not* scan your source tree, trying to
figure out which directories correspond to Python packages by looking for
:file:`__init__.py` files.) Thus, if the default layout grows a sub-package::
/
setup.py
foobar/
__init__.py
foo.py
bar.py
subfoo/
__init__.py
blah.py
then the corresponding setup script would be ::
from distutils.core import setup
setup(name='foobar',
version='1.0',
packages=['foobar', 'foobar.subfoo'],
)
.. _single-ext:
Single extension module
=======================
Extension modules are specified using the ``ext_modules`` option.
``package_dir`` has no effect on where extension source files are found;
it only affects the source for pure Python modules. The simplest case, a
single extension module in a single C source file, is::
/
setup.py
foo.c
If the ``foo`` extension belongs in the root package, the setup script for
this could be ::
from distutils.core import setup
from distutils.extension import Extension
setup(name='foobar',
version='1.0',
ext_modules=[Extension('foo', ['foo.c'])],
)
If the extension actually belongs in a package, say ``foopkg``, then
With exactly the same source tree layout, this extension can be put in the
``foopkg`` package simply by changing the name of the extension::
from distutils.core import setup
from distutils.extension import Extension
setup(name='foobar',
version='1.0',
ext_modules=[Extension('foopkg.foo', ['foo.c'])],
)
Checking a package
==================
The ``check`` command allows you to verify if your package meta-data
meet the minimum requirements to build a distribution.
To run it, just call it using your :file:`setup.py` script. If something is
missing, ``check`` will display a warning.
Let's take an example with a simple script::
from distutils.core import setup
setup(name='foobar')
Running the ``check`` command will display some warnings:
.. code-block:: shell-session
$ python setup.py check
running check
warning: check: missing required meta-data: version
If you use the reStructuredText syntax in the ``long_description`` field and
`docutils`_ is installed you can check if the syntax is fine with the
``check`` command, using the ``restructuredtext`` option.
For example, if the :file:`setup.py` script is changed like this::
from distutils.core import setup
desc = """\
My description
==============
This is the description of the ``foobar`` package.
"""
setup(name='foobar', version='1', author='tarek',
author_email='tarek@ziade.org',
url='http://example.com', long_description=desc)
Where the long description is broken, ``check`` will be able to detect it
by using the :mod:`docutils` parser:
.. code-block:: shell-session
$ python setup.py check --restructuredtext
running check
warning: check: Title underline too short. (line 2)
warning: check: Could not finish the parsing.
Reading the metadata
=====================
The :func:`distutils.core.setup` function provides a command-line interface
that allows you to query the metadata fields of a project through the
``setup.py`` script of a given project:
.. code-block:: shell-session
$ python setup.py --name
distribute
This call reads the ``name`` metadata by running the
:func:`distutils.core.setup` function. Although, when a source or binary
distribution is created with Distutils, the metadata fields are written
in a static file called :file:`PKG-INFO`. When a Distutils-based project is
installed in Python, the :file:`PKG-INFO` file is copied alongside the modules
and packages of the distribution under :file:`NAME-VERSION-pyX.X.egg-info`,
where ``NAME`` is the name of the project, ``VERSION`` its version as defined
in the Metadata, and ``pyX.X`` the major and minor version of Python like
``2.7`` or ``3.2``.
You can read back this static file, by using the
:class:`distutils.dist.DistributionMetadata` class and its
:func:`~distutils.dist.DistributionMetadata.read_pkg_file` method::
>>> from distutils.dist import DistributionMetadata
>>> metadata = DistributionMetadata()
>>> metadata.read_pkg_file(open('distribute-0.6.8-py2.7.egg-info'))
>>> metadata.name
'distribute'
>>> metadata.version
'0.6.8'
>>> metadata.description
'Easily download, build, install, upgrade, and uninstall Python packages'
Notice that the class can also be instantiated with a metadata file path to
loads its values::
>>> pkg_info_path = 'distribute-0.6.8-py2.7.egg-info'
>>> DistributionMetadata(pkg_info_path).name
'distribute'
.. % \section{Multiple extension modules}
.. % \label{multiple-ext}
.. % \section{Putting it all together}
.. _docutils: http://docutils.sourceforge.net
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/extending.rst 0000644 0001751 0000173 00000010756 14467657412 023256 0 ustar 00runner docker .. _extending-distutils:
*******************
Extending Distutils
*******************
.. include:: ./_setuptools_disclaimer.rst
Distutils can be extended in various ways. Most extensions take the form of new
commands or replacements for existing commands. New commands may be written to
support new types of platform-specific packaging, for example, while
replacements for existing commands may be made to modify details of how the
command operates on a package.
Most extensions of the distutils are made within :file:`setup.py` scripts that
want to modify existing commands; many simply add a few file extensions that
should be copied into packages in addition to :file:`.py` files as a
convenience.
Most distutils command implementations are subclasses of the
:class:`distutils.cmd.Command` class. New commands may directly inherit from
:class:`~distutils.cmd.Command`, while replacements often derive from :class:`~distutils.cmd.Command`
indirectly, directly subclassing the command they are replacing. Commands are
required to derive from :class:`~distutils.cmd.Command`.
.. % \section{Extending existing commands}
.. % \label{extend-existing}
.. % \section{Writing new commands}
.. % \label{new-commands}
.. % \XXX{Would an uninstall command be a good example here?}
Integrating new commands
========================
There are different ways to integrate new command implementations into
distutils. The most difficult is to lobby for the inclusion of the new features
in distutils itself, and wait for (and require) a version of Python that
provides that support. This is really hard for many reasons.
The most common, and possibly the most reasonable for most needs, is to include
the new implementations with your :file:`setup.py` script, and cause the
:func:`distutils.core.setup` function use them::
from distutils.command.build_py import build_py as _build_py
from distutils.core import setup
class build_py(_build_py):
"""Specialized Python source builder."""
# implement whatever needs to be different...
setup(cmdclass={'build_py': build_py},
...)
This approach is most valuable if the new implementations must be used to use a
particular package, as everyone interested in the package will need to have the
new command implementation.
Beginning with Python 2.4, a third option is available, intended to allow new
commands to be added which can support existing :file:`setup.py` scripts without
requiring modifications to the Python installation. This is expected to allow
third-party extensions to provide support for additional packaging systems, but
the commands can be used for anything distutils commands can be used for. A new
configuration option, ``command_packages`` (command-line option
:option:`!--command-packages`), can be used to specify additional packages to be
searched for modules implementing commands. Like all distutils options, this
can be specified on the command line or in a configuration file. This option
can only be set in the ``[global]`` section of a configuration file, or before
any commands on the command line. If set in a configuration file, it can be
overridden from the command line; setting it to an empty string on the command
line causes the default to be used. This should never be set in a configuration
file provided with a package.
This new option can be used to add any number of packages to the list of
packages searched for command implementations; multiple package names should be
separated by commas. When not specified, the search is only performed in the
:mod:`distutils.command` package. When :file:`setup.py` is run with the option
``--command-packages distcmds,buildcmds``, however, the packages
:mod:`distutils.command`, ``distcmds``, and ``buildcmds`` will be searched
in that order. New commands are expected to be implemented in modules of the
same name as the command by classes sharing the same name. Given the example
command line option above, the command :command:`bdist_openpkg` could be
implemented by the class ``distcmds.bdist_openpkg.bdist_openpkg`` or
``buildcmds.bdist_openpkg.bdist_openpkg``.
Adding new distribution types
=============================
Commands that create distributions (files in the :file:`dist/` directory) need
to add ``(command, filename)`` pairs to ``self.distribution.dist_files`` so that
:command:`upload` can upload it to PyPI. The *filename* in the pair contains no
path information, only the name of the file itself. In dry-run mode, pairs
should still be added to represent what would have been created.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/index.rst 0000644 0001751 0000173 00000002353 14467657412 022372 0 ustar 00runner docker .. _distutils-index:
##############################################
Distributing Python Modules (Legacy version)
##############################################
:Authors: Greg Ward, Anthony Baxter
:Email: distutils-sig@python.org
.. seealso::
:ref:`distributing-index`
The up to date module distribution documentations
.. include:: ./_setuptools_disclaimer.rst
.. note::
This guide only covers the basic tools for building and distributing
extensions that are provided as part of this version of Python. Third party
tools offer easier to use and more secure alternatives. Refer to the `quick
recommendations section `__
in the Python Packaging User Guide for more information.
This document describes the Python Distribution Utilities ("Distutils") from
the module developer's point of view, describing the underlying capabilities
that ``setuptools`` builds on to allow Python developers to make Python modules
and extensions readily available to a wider audience.
.. toctree::
:maxdepth: 2
:numbered:
introduction.rst
setupscript.rst
configfile.rst
sourcedist.rst
builtdist.rst
examples.rst
extending.rst
commandref.rst
apiref.rst
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/introduction.rst 0000644 0001751 0000173 00000017606 14467657412 024013 0 ustar 00runner docker .. _distutils-intro:
****************************
An Introduction to Distutils
****************************
.. include:: ./_setuptools_disclaimer.rst
This document covers using the Distutils to distribute your Python modules,
concentrating on the role of developer/distributor: if you're looking for
information on installing Python modules, you should refer to the
:ref:`install-index` chapter.
.. _distutils-concepts:
Concepts & Terminology
======================
Using the Distutils is quite simple, both for module developers and for
users/administrators installing third-party modules. As a developer, your
responsibilities (apart from writing solid, well-documented and well-tested
code, of course!) are:
* write a setup script (:file:`setup.py` by convention)
* (optional) write a setup configuration file
* create a source distribution
* (optional) create one or more built (binary) distributions
Each of these tasks is covered in this document.
Not all module developers have access to a multitude of platforms, so it's not
always feasible to expect them to create a multitude of built distributions. It
is hoped that a class of intermediaries, called *packagers*, will arise to
address this need. Packagers will take source distributions released by module
developers, build them on one or more platforms, and release the resulting built
distributions. Thus, users on the most popular platforms will be able to
install most popular Python module distributions in the most natural way for
their platform, without having to run a single setup script or compile a line of
code.
.. _distutils-simple-example:
A Simple Example
================
The setup script is usually quite simple, although since it's written in Python,
there are no arbitrary limits to what you can do with it, though you should be
careful about putting arbitrarily expensive operations in your setup script.
Unlike, say, Autoconf-style configure scripts, the setup script may be run
multiple times in the course of building and installing your module
distribution.
If all you want to do is distribute a module called ``foo``, contained in a
file :file:`foo.py`, then your setup script can be as simple as this::
from distutils.core import setup
setup(name='foo',
version='1.0',
py_modules=['foo'],
)
Some observations:
* most information that you supply to the Distutils is supplied as keyword
arguments to the :func:`~distutils.core.setup` function
* those keyword arguments fall into two categories: package metadata (name,
version number) and information about what's in the package (a list of pure
Python modules, in this case)
* modules are specified by module name, not filename (the same will hold true
for packages and extensions)
* it's recommended that you supply a little more metadata, in particular your
name, email address and a URL for the project (see section :ref:`setup-script`
for an example)
To create a source distribution for this module, you would create a setup
script, :file:`setup.py`, containing the above code, and run this command from a
terminal::
python setup.py sdist
For Windows, open a command prompt window (:menuselection:`Start -->
Accessories`) and change the command to::
setup.py sdist
:command:`sdist` will create an archive file (e.g., tarball on Unix, ZIP file on Windows)
containing your setup script :file:`setup.py`, and your module :file:`foo.py`.
The archive file will be named :file:`foo-1.0.tar.gz` (or :file:`.zip`), and
will unpack into a directory :file:`foo-1.0`.
If an end-user wishes to install your ``foo`` module, all they have to do is
download :file:`foo-1.0.tar.gz` (or :file:`.zip`), unpack it, and---from the
:file:`foo-1.0` directory---run ::
python setup.py install
which will ultimately copy :file:`foo.py` to the appropriate directory for
third-party modules in their Python installation.
This simple example demonstrates some fundamental concepts of the Distutils.
First, both developers and installers have the same basic user interface, i.e.
the setup script. The difference is which Distutils *commands* they use: the
:command:`sdist` command is almost exclusively for module developers, while
:command:`install` is more often for installers (although most developers will
want to install their own code occasionally).
Other useful built distribution formats are RPM, implemented by the
:command:`bdist_rpm` command, Solaris :program:`pkgtool`
(:command:`bdist_pkgtool`), and HP-UX :program:`swinstall`
(:command:`bdist_sdux`). For example, the following command will create an RPM
file called :file:`foo-1.0.noarch.rpm`::
python setup.py bdist_rpm
(The :command:`bdist_rpm` command uses the :command:`rpm` executable, therefore
this has to be run on an RPM-based system such as Red Hat Linux, SuSE Linux, or
Mandrake Linux.)
You can find out what distribution formats are available at any time by running
::
python setup.py bdist --help-formats
.. _python-terms:
General Python terminology
==========================
If you're reading this document, you probably have a good idea of what modules,
extensions, and so forth are. Nevertheless, just to be sure that everyone is
operating from a common starting point, we offer the following glossary of
common Python terms:
module
the basic unit of code reusability in Python: a block of code imported by some
other code. Three types of modules concern us here: pure Python modules,
extension modules, and packages.
pure Python module
a module written in Python and contained in a single :file:`.py` file (and
possibly associated :file:`.pyc` files). Sometimes referred to as a
"pure module."
extension module
a module written in the low-level language of the Python implementation: C/C++
for Python, Java for Jython. Typically contained in a single dynamically
loadable pre-compiled file, e.g. a shared object (:file:`.so`) file for Python
extensions on Unix, a DLL (given the :file:`.pyd` extension) for Python
extensions on Windows, or a Java class file for Jython extensions. (Note that
currently, the Distutils only handles C/C++ extensions for Python.)
package
a module that contains other modules; typically contained in a directory in the
filesystem and distinguished from other directories by the presence of a file
:file:`__init__.py`.
root package
the root of the hierarchy of packages. (This isn't really a package, since it
doesn't have an :file:`__init__.py` file. But we have to call it something.)
The vast majority of the standard library is in the root package, as are many
small, standalone third-party modules that don't belong to a larger module
collection. Unlike regular packages, modules in the root package can be found in
many directories: in fact, every directory listed in ``sys.path`` contributes
modules to the root package.
.. _distutils-term:
Distutils-specific terminology
==============================
The following terms apply more specifically to the domain of distributing Python
modules using the Distutils:
module distribution
a collection of Python modules distributed together as a single downloadable
resource and meant to be installed *en masse*. Examples of some well-known
module distributions are NumPy, SciPy, Pillow,
or mxBase. (This would be called a *package*, except that term is
already taken in the Python context: a single module distribution may contain
zero, one, or many Python packages.)
pure module distribution
a module distribution that contains only pure Python modules and packages.
Sometimes referred to as a "pure distribution."
non-pure module distribution
a module distribution that contains at least one extension module. Sometimes
referred to as a "non-pure distribution."
distribution root
the top-level directory of your source tree (or source distribution); the
directory where :file:`setup.py` exists. Generally :file:`setup.py` will be
run from this directory.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/packageindex.rst 0000644 0001751 0000173 00000000700 14467657412 023700 0 ustar 00runner docker :orphan:
.. _package-index:
*******************************
The Python Package Index (PyPI)
*******************************
The `Python Package Index (PyPI)`_ stores metadata describing distributions
packaged with distutils and other publishing tools, as well the distribution
archives themselves.
References to up to date PyPI documentation can be found at
:ref:`publishing-python-packages`.
.. _Python Package Index (PyPI): https://pypi.org
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/setupscript.rst 0000644 0001751 0000173 00000075146 14467657412 023662 0 ustar 00runner docker .. _setup-script:
************************
Writing the Setup Script
************************
.. include:: ./_setuptools_disclaimer.rst
The setup script is the centre of all activity in building, distributing, and
installing modules using the Distutils. The main purpose of the setup script is
to describe your module distribution to the Distutils, so that the various
commands that operate on your modules do the right thing. As we saw in section
:ref:`distutils-simple-example` above, the setup script consists mainly of a call to :func:`~distutils.core.setup`, and most information
supplied to the Distutils by the module developer is supplied as keyword
arguments to :func:`~distutils.core.setup`.
Here's a slightly more involved example, which we'll follow for the next couple
of sections: the Distutils' own setup script. (Keep in mind that although the
Distutils are included with Python 1.6 and later, they also have an independent
existence so that Python 1.5.2 users can use them to install other module
distributions. The Distutils' own setup script, shown here, is used to install
the package into Python 1.5.2.) ::
#!/usr/bin/env python
from distutils.core import setup
setup(name='Distutils',
version='1.0',
description='Python Distribution Utilities',
author='Greg Ward',
author_email='gward@python.net',
url='https://www.python.org/sigs/distutils-sig/',
packages=['distutils', 'distutils.command'],
)
There are only two differences between this and the trivial one-file
distribution presented in section :ref:`distutils-simple-example`: more metadata, and the
specification of pure Python modules by package, rather than by module. This is
important since the Distutils consist of a couple of dozen modules split into
(so far) two packages; an explicit list of every module would be tedious to
generate and difficult to maintain. For more information on the additional
meta-data, see section :ref:`meta-data`.
Note that any pathnames (files or directories) supplied in the setup script
should be written using the Unix convention, i.e. slash-separated. The
Distutils will take care of converting this platform-neutral representation into
whatever is appropriate on your current platform before actually using the
pathname. This makes your setup script portable across operating systems, which
of course is one of the major goals of the Distutils. In this spirit, all
pathnames in this document are slash-separated.
This, of course, only applies to pathnames given to Distutils functions. If
you, for example, use standard Python functions such as :func:`glob.glob` or
:func:`os.listdir` to specify files, you should be careful to write portable
code instead of hardcoding path separators::
glob.glob(os.path.join('mydir', 'subdir', '*.html'))
os.listdir(os.path.join('mydir', 'subdir'))
.. _listing-packages:
Listing whole packages
======================
The ``packages`` option tells the Distutils to process (build, distribute,
install, etc.) all pure Python modules found in each package mentioned in the
``packages`` list. In order to do this, of course, there has to be a
correspondence between package names and directories in the filesystem. The
default correspondence is the most obvious one, i.e. package :mod:`distutils` is
found in the directory :file:`distutils` relative to the distribution root.
Thus, when you say ``packages = ['foo']`` in your setup script, you are
promising that the Distutils will find a file :file:`foo/__init__.py` (which
might be spelled differently on your system, but you get the idea) relative to
the directory where your setup script lives. If you break this promise, the
Distutils will issue a warning but still process the broken package anyway.
If you use a different convention to lay out your source directory, that's no
problem: you just have to supply the ``package_dir`` option to tell the
Distutils about your convention. For example, say you keep all Python source
under :file:`lib`, so that modules in the "root package" (i.e., not in any
package at all) are in :file:`lib`, modules in the ``foo`` package are in
:file:`lib/foo`, and so forth. Then you would put ::
package_dir = {'': 'lib'}
in your setup script. The keys to this dictionary are package names, and an
empty package name stands for the root package. The values are directory names
relative to your distribution root. In this case, when you say ``packages =
['foo']``, you are promising that the file :file:`lib/foo/__init__.py` exists.
Another possible convention is to put the ``foo`` package right in
:file:`lib`, the ``foo.bar`` package in :file:`lib/bar`, etc. This would be
written in the setup script as ::
package_dir = {'foo': 'lib'}
A ``package: dir`` entry in the ``package_dir`` dictionary implicitly
applies to all packages below *package*, so the ``foo.bar`` case is
automatically handled here. In this example, having ``packages = ['foo',
'foo.bar']`` tells the Distutils to look for :file:`lib/__init__.py` and
:file:`lib/bar/__init__.py`. (Keep in mind that although ``package_dir``
applies recursively, you must explicitly list all packages in
``packages``: the Distutils will *not* recursively scan your source tree
looking for any directory with an :file:`__init__.py` file.)
.. _listing-modules:
Listing individual modules
==========================
For a small module distribution, you might prefer to list all modules rather
than listing packages---especially the case of a single module that goes in the
"root package" (i.e., no package at all). This simplest case was shown in
section :ref:`distutils-simple-example`; here is a slightly more involved example::
py_modules = ['mod1', 'pkg.mod2']
This describes two modules, one of them in the "root" package, the other in the
``pkg`` package. Again, the default package/directory layout implies that
these two modules can be found in :file:`mod1.py` and :file:`pkg/mod2.py`, and
that :file:`pkg/__init__.py` exists as well. And again, you can override the
package/directory correspondence using the ``package_dir`` option.
.. _describing-extensions:
Describing extension modules
============================
Just as writing Python extension modules is a bit more complicated than writing
pure Python modules, describing them to the Distutils is a bit more complicated.
Unlike pure modules, it's not enough just to list modules or packages and expect
the Distutils to go out and find the right files; you have to specify the
extension name, source file(s), and any compile/link requirements (include
directories, libraries to link with, etc.).
.. XXX read over this section
All of this is done through another keyword argument to
:func:`~distutils.core.setup`, the
``ext_modules`` option. ``ext_modules`` is just a list of
:class:`~distutils.core.Extension` instances, each of which describes a
single extension module.
Suppose your distribution includes a single extension, called ``foo`` and
implemented by :file:`foo.c`. If no additional instructions to the
compiler/linker are needed, describing this extension is quite simple::
Extension('foo', ['foo.c'])
The :class:`~distutils.extension.Extension` class can be imported from :mod:`distutils.core` along
with :func:`~distutils.core.setup`. Thus, the setup script for a module distribution that
contains only this one extension and nothing else might be::
from distutils.core import setup, Extension
setup(name='foo',
version='1.0',
ext_modules=[Extension('foo', ['foo.c'])],
)
The :class:`~distutils.extension.Extension` class (actually, the underlying extension-building
machinery implemented by the :command:`build_ext` command) supports a great deal
of flexibility in describing Python extensions, which is explained in the
following sections.
Extension names and packages
----------------------------
The first argument to the :class:`~distutils.core.Extension` constructor is
always the name of the extension, including any package names. For example, ::
Extension('foo', ['src/foo1.c', 'src/foo2.c'])
describes an extension that lives in the root package, while ::
Extension('pkg.foo', ['src/foo1.c', 'src/foo2.c'])
describes the same extension in the ``pkg`` package. The source files and
resulting object code are identical in both cases; the only difference is where
in the filesystem (and therefore where in Python's namespace hierarchy) the
resulting extension lives.
If you have a number of extensions all in the same package (or all under the
same base package), use the ``ext_package`` keyword argument to
:func:`~distutils.core.setup`. For example, ::
setup(...,
ext_package='pkg',
ext_modules=[Extension('foo', ['foo.c']),
Extension('subpkg.bar', ['bar.c'])],
)
will compile :file:`foo.c` to the extension ``pkg.foo``, and
:file:`bar.c` to ``pkg.subpkg.bar``.
Extension source files
----------------------
The second argument to the :class:`~distutils.core.Extension` constructor is
a list of source
files. Since the Distutils currently only support C, C++, and Objective-C
extensions, these are normally C/C++/Objective-C source files. (Be sure to use
appropriate extensions to distinguish C++ source files: :file:`.cc` and
:file:`.cpp` seem to be recognized by both Unix and Windows compilers.)
However, you can also include SWIG interface (:file:`.i`) files in the list; the
:command:`build_ext` command knows how to deal with SWIG extensions: it will run
SWIG on the interface file and compile the resulting C/C++ file into your
extension.
.. XXX SWIG support is rough around the edges and largely untested!
This warning notwithstanding, options to SWIG can be currently passed like
this::
setup(...,
ext_modules=[Extension('_foo', ['foo.i'],
swig_opts=['-modern', '-I../include'])],
py_modules=['foo'],
)
Or on the commandline like this::
> python setup.py build_ext --swig-opts="-modern -I../include"
On some platforms, you can include non-source files that are processed by the
compiler and included in your extension. Currently, this just means Windows
message text (:file:`.mc`) files and resource definition (:file:`.rc`) files for
Visual C++. These will be compiled to binary resource (:file:`.res`) files and
linked into the executable.
Preprocessor options
--------------------
Three optional arguments to :class:`~distutils.core.Extension` will help if
you need to specify include directories to search or preprocessor macros to
define/undefine: ``include_dirs``, ``define_macros``, and ``undef_macros``.
For example, if your extension requires header files in the :file:`include`
directory under your distribution root, use the ``include_dirs`` option::
Extension('foo', ['foo.c'], include_dirs=['include'])
You can specify absolute directories there; if you know that your extension will
only be built on Unix systems with X11R6 installed to :file:`/usr`, you can get
away with ::
Extension('foo', ['foo.c'], include_dirs=['/usr/include/X11'])
You should avoid this sort of non-portable usage if you plan to distribute your
code: it's probably better to write C code like ::
#include
If you need to include header files from some other Python extension, you can
take advantage of the fact that header files are installed in a consistent way
by the Distutils :command:`install_headers` command. For example, the Numerical
Python header files are installed (on a standard Unix installation) to
:file:`/usr/local/include/python1.5/Numerical`. (The exact location will differ
according to your platform and Python installation.) Since the Python include
directory---\ :file:`/usr/local/include/python1.5` in this case---is always
included in the search path when building Python extensions, the best approach
is to write C code like ::
#include
If you must put the :file:`Numerical` include directory right into your header
search path, though, you can find that directory using the Distutils
:mod:`distutils.sysconfig` module::
from distutils.sysconfig import get_python_inc
incdir = os.path.join(get_python_inc(plat_specific=1), 'Numerical')
setup(...,
Extension(..., include_dirs=[incdir]),
)
Even though this is quite portable---it will work on any Python installation,
regardless of platform---it's probably easier to just write your C code in the
sensible way.
You can define and undefine pre-processor macros with the ``define_macros`` and
``undef_macros`` options. ``define_macros`` takes a list of ``(name, value)``
tuples, where ``name`` is the name of the macro to define (a string) and
``value`` is its value: either a string or ``None``. (Defining a macro ``FOO``
to ``None`` is the equivalent of a bare ``#define FOO`` in your C source: with
most compilers, this sets ``FOO`` to the string ``1``.) ``undef_macros`` is
just a list of macros to undefine.
For example::
Extension(...,
define_macros=[('NDEBUG', '1'),
('HAVE_STRFTIME', None)],
undef_macros=['HAVE_FOO', 'HAVE_BAR'])
is the equivalent of having this at the top of every C source file::
#define NDEBUG 1
#define HAVE_STRFTIME
#undef HAVE_FOO
#undef HAVE_BAR
Library options
---------------
You can also specify the libraries to link against when building your extension,
and the directories to search for those libraries. The ``libraries`` option is
a list of libraries to link against, ``library_dirs`` is a list of directories
to search for libraries at link-time, and ``runtime_library_dirs`` is a list of
directories to search for shared (dynamically loaded) libraries at run-time.
For example, if you need to link against libraries known to be in the standard
library search path on target systems ::
Extension(...,
libraries=['gdbm', 'readline'])
If you need to link with libraries in a non-standard location, you'll have to
include the location in ``library_dirs``::
Extension(...,
library_dirs=['/usr/X11R6/lib'],
libraries=['X11', 'Xt'])
(Again, this sort of non-portable construct should be avoided if you intend to
distribute your code.)
.. XXX Should mention clib libraries here or somewhere else!
Other options
-------------
There are still some other options which can be used to handle special cases.
The ``optional`` option is a boolean; if it is true,
a build failure in the extension will not abort the build process, but
instead simply not install the failing extension.
The ``extra_objects`` option is a list of object files to be passed to the
linker. These files must not have extensions, as the default extension for the
compiler is used.
``extra_compile_args`` and ``extra_link_args`` can be used to
specify additional command line options for the respective compiler and linker
command lines.
``export_symbols`` is only useful on Windows. It can contain a list of
symbols (functions or variables) to be exported. This option is not needed when
building compiled extensions: Distutils will automatically add ``initmodule``
to the list of exported symbols.
The ``depends`` option is a list of files that the extension depends on
(for example header files). The build command will call the compiler on the
sources to rebuild extension if any on this files has been modified since the
previous build.
Relationships between Distributions and Packages
================================================
A distribution may relate to packages in three specific ways:
#. It can require packages or modules.
#. It can provide packages or modules.
#. It can obsolete packages or modules.
These relationships can be specified using keyword arguments to the
:func:`distutils.core.setup` function.
Dependencies on other Python modules and packages can be specified by supplying
the *requires* keyword argument to :func:`~distutils.core.setup`. The
value must be a list of
strings. Each string specifies a package that is required, and optionally what
versions are sufficient.
To specify that any version of a module or package is required, the string
should consist entirely of the module or package name. Examples include
``'mymodule'`` and ``'xml.parsers.expat'``.
If specific versions are required, a sequence of qualifiers can be supplied in
parentheses. Each qualifier may consist of a comparison operator and a version
number. The accepted comparison operators are::
< > ==
<= >= !=
These can be combined by using multiple qualifiers separated by commas (and
optional whitespace). In this case, all of the qualifiers must be matched; a
logical AND is used to combine the evaluations.
Let's look at a bunch of examples:
+-------------------------+----------------------------------------------+
| Requires Expression | Explanation |
+=========================+==============================================+
| ``==1.0`` | Only version ``1.0`` is compatible |
+-------------------------+----------------------------------------------+
| ``>1.0, !=1.5.1, <2.0`` | Any version after ``1.0`` and before ``2.0`` |
| | is compatible, except ``1.5.1`` |
+-------------------------+----------------------------------------------+
Now that we can specify dependencies, we also need to be able to specify what we
provide that other distributions can require. This is done using the *provides*
keyword argument to :func:`~distutils.core.setup`. The value for this keyword is a list of
strings, each of which names a Python module or package, and optionally
identifies the version. If the version is not specified, it is assumed to match
that of the distribution.
Some examples:
+---------------------+----------------------------------------------+
| Provides Expression | Explanation |
+=====================+==============================================+
| ``mypkg`` | Provide ``mypkg``, using the distribution |
| | version |
+---------------------+----------------------------------------------+
| ``mypkg (1.1)`` | Provide ``mypkg`` version 1.1, regardless of |
| | the distribution version |
+---------------------+----------------------------------------------+
A package can declare that it obsoletes other packages using the *obsoletes*
keyword argument. The value for this is similar to that of the *requires*
keyword: a list of strings giving module or package specifiers. Each specifier
consists of a module or package name optionally followed by one or more version
qualifiers. Version qualifiers are given in parentheses after the module or
package name.
The versions identified by the qualifiers are those that are obsoleted by the
distribution being described. If no qualifiers are given, all versions of the
named module or package are understood to be obsoleted.
.. _distutils-installing-scripts:
Installing Scripts
==================
So far we have been dealing with pure and non-pure Python modules, which are
usually not run by themselves but imported by scripts.
Scripts are files containing Python source code, intended to be started from the
command line. Scripts don't require Distutils to do anything very complicated.
The only clever feature is that if the first line of the script starts with
``#!`` and contains the word "python", the Distutils will adjust the first line
to refer to the current interpreter location. By default, it is replaced with
the current interpreter location. The :option:`!--executable` (or :option:`!-e`)
option will allow the interpreter path to be explicitly overridden.
The ``scripts`` option simply is a list of files to be handled in this
way. From the PyXML setup script::
setup(...,
scripts=['scripts/xmlproc_parse', 'scripts/xmlproc_val']
)
.. versionchanged:: 3.1
All the scripts will also be added to the ``MANIFEST`` file if no template is
provided. See :ref:`manifest`.
.. _distutils-installing-package-data:
Installing Package Data
=======================
Often, additional files need to be installed into a package. These files are
often data that's closely related to the package's implementation, or text files
containing documentation that might be of interest to programmers using the
package. These files are called :dfn:`package data`.
Package data can be added to packages using the ``package_data`` keyword
argument to the :func:`~distutils.core.setup` function. The value must be a mapping from
package name to a list of relative path names that should be copied into the
package. The paths are interpreted as relative to the directory containing the
package (information from the ``package_dir`` mapping is used if appropriate);
that is, the files are expected to be part of the package in the source
directories. They may contain glob patterns as well.
The path names may contain directory portions; any necessary directories will be
created in the installation.
For example, if a package should contain a subdirectory with several data files,
the files can be arranged like this in the source tree::
setup.py
src/
mypkg/
__init__.py
module.py
data/
tables.dat
spoons.dat
forks.dat
The corresponding call to :func:`~distutils.core.setup` might be::
setup(...,
packages=['mypkg'],
package_dir={'mypkg': 'src/mypkg'},
package_data={'mypkg': ['data/*.dat']},
)
.. versionchanged:: 3.1
All the files that match ``package_data`` will be added to the ``MANIFEST``
file if no template is provided. See :ref:`manifest`.
.. _distutils-additional-files:
Installing Additional Files
===========================
The ``data_files`` option can be used to specify additional files needed
by the module distribution: configuration files, message catalogs, data files,
anything which doesn't fit in the previous categories.
``data_files`` specifies a sequence of (*directory*, *files*) pairs in the
following way::
setup(...,
data_files=[('bitmaps', ['bm/b1.gif', 'bm/b2.gif']),
('config', ['cfg/data.cfg'])],
)
Each (*directory*, *files*) pair in the sequence specifies the installation
directory and the files to install there.
Each file name in *files* is interpreted relative to the :file:`setup.py`
script at the top of the package source distribution. Note that you can
specify the directory where the data files will be installed, but you cannot
rename the data files themselves.
The *directory* should be a relative path. It is interpreted relative to the
installation prefix (Python's ``sys.prefix`` for system installations;
``site.USER_BASE`` for user installations). Distutils allows *directory* to be
an absolute installation path, but this is discouraged since it is
incompatible with the wheel packaging format. No directory information from
*files* is used to determine the final location of the installed file; only
the name of the file is used.
You can specify the ``data_files`` options as a simple sequence of files
without specifying a target directory, but this is not recommended, and the
:command:`install` command will print a warning in this case. To install data
files directly in the target directory, an empty string should be given as the
directory.
.. versionchanged:: 3.1
All the files that match ``data_files`` will be added to the ``MANIFEST``
file if no template is provided. See :ref:`manifest`.
.. _meta-data:
Additional meta-data
====================
The setup script may include additional meta-data beyond the name and version.
This information includes:
+----------------------+---------------------------+-----------------+--------+
| Meta-Data | Description | Value | Notes |
+======================+===========================+=================+========+
| ``name`` | name of the package | short string | \(1) |
+----------------------+---------------------------+-----------------+--------+
| ``version`` | version of this release | short string | (1)(2) |
+----------------------+---------------------------+-----------------+--------+
| ``author`` | package author's name | short string | \(3) |
+----------------------+---------------------------+-----------------+--------+
| ``author_email`` | email address of the | email address | \(3) |
| | package author | | |
+----------------------+---------------------------+-----------------+--------+
| ``maintainer`` | package maintainer's name | short string | \(3) |
+----------------------+---------------------------+-----------------+--------+
| ``maintainer_email`` | email address of the | email address | \(3) |
| | package maintainer | | |
+----------------------+---------------------------+-----------------+--------+
| ``url`` | home page for the package | URL | |
+----------------------+---------------------------+-----------------+--------+
| ``description`` | short, summary | short string | |
| | description of the | | |
| | package | | |
+----------------------+---------------------------+-----------------+--------+
| ``long_description`` | longer description of the | long string | \(4) |
| | package | | |
+----------------------+---------------------------+-----------------+--------+
| ``download_url`` | location where the | URL | |
| | package may be downloaded | | |
+----------------------+---------------------------+-----------------+--------+
| ``classifiers`` | a list of classifiers | list of strings | (6)(7) |
+----------------------+---------------------------+-----------------+--------+
| ``platforms`` | a list of platforms | list of strings | (6)(8) |
+----------------------+---------------------------+-----------------+--------+
| ``keywords`` | a list of keywords | list of strings | (6)(8) |
+----------------------+---------------------------+-----------------+--------+
| ``license`` | license for the package | short string | \(5) |
+----------------------+---------------------------+-----------------+--------+
Notes:
(1)
These fields are required.
(2)
It is recommended that versions take the form *major.minor[.patch[.sub]]*.
(3)
If maintainer is provided and author is not, distutils lists maintainer as
the author in :file:`PKG-INFO`.
(4)
The ``long_description`` field is used by PyPI when you publish a package,
to build its project page.
(5)
The ``license`` field is a text indicating the license covering the
package where the license is not a selection from the "License" Trove
classifiers. See the ``Classifier`` field. Notice that
there's a ``licence`` distribution option which is deprecated but still
acts as an alias for ``license``.
(6)
This field must be a list.
(7)
The valid classifiers are listed on
`PyPI `_.
(8)
To preserve backward compatibility, this field also accepts a string. If
you pass a comma-separated string ``'foo, bar'``, it will be converted to
``['foo', 'bar']``, Otherwise, it will be converted to a list of one
string.
'short string'
A single line of text, not more than 200 characters.
'long string'
Multiple lines of plain text in reStructuredText format (see
http://docutils.sourceforge.net/).
'list of strings'
See below.
Encoding the version information is an art in itself. Python packages generally
adhere to the version format *major.minor[.patch][sub]*. The major number is 0
for initial, experimental releases of software. It is incremented for releases
that represent major milestones in a package. The minor number is incremented
when important new features are added to the package. The patch number
increments when bug-fix releases are made. Additional trailing version
information is sometimes used to indicate sub-releases. These are
"a1,a2,...,aN" (for alpha releases, where functionality and API may change),
"b1,b2,...,bN" (for beta releases, which only fix bugs) and "pr1,pr2,...,prN"
(for final pre-release release testing). Some examples:
0.1.0
the first, experimental release of a package
1.0.1a2
the second alpha release of the first patch version of 1.0
``classifiers`` must be specified in a list::
setup(...,
classifiers=[
'Development Status :: 4 - Beta',
'Environment :: Console',
'Environment :: Web Environment',
'Intended Audience :: End Users/Desktop',
'Intended Audience :: Developers',
'Intended Audience :: System Administrators',
'License :: OSI Approved :: Python Software Foundation License',
'Operating System :: MacOS :: MacOS X',
'Operating System :: Microsoft :: Windows',
'Operating System :: POSIX',
'Programming Language :: Python',
'Topic :: Communications :: Email',
'Topic :: Office/Business',
'Topic :: Software Development :: Bug Tracking',
],
)
.. versionchanged:: 3.7
:class:`~distutils.core.setup` now warns when ``classifiers``, ``keywords``
or ``platforms`` fields are not specified as a list or a string.
.. _debug-setup-script:
Debugging the setup script
==========================
Sometimes things go wrong, and the setup script doesn't do what the developer
wants.
Distutils catches any exceptions when running the setup script, and print a
simple error message before the script is terminated. The motivation for this
behaviour is to not confuse administrators who don't know much about Python and
are trying to install a package. If they get a big long traceback from deep
inside the guts of Distutils, they may think the package or the Python
installation is broken because they don't read all the way down to the bottom
and see that it's a permission problem.
On the other hand, this doesn't help the developer to find the cause of the
failure. For this purpose, the :envvar:`DISTUTILS_DEBUG` environment variable can be set
to anything except an empty string, and distutils will now print detailed
information about what it is doing, dump the full traceback when an exception
occurs, and print the whole command line when an external program (like a C
compiler) fails.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/sourcedist.rst 0000644 0001751 0000173 00000023015 14467657412 023445 0 ustar 00runner docker .. _source-dist:
******************************
Creating a Source Distribution
******************************
.. include:: ./_setuptools_disclaimer.rst
As shown in section :ref:`distutils-simple-example`, you use the :command:`sdist` command
to create a source distribution. In the simplest case, ::
python setup.py sdist
(assuming you haven't specified any :command:`sdist` options in the setup script
or config file), :command:`sdist` creates the archive of the default format for
the current platform. The default format is a gzip'ed tar file
(:file:`.tar.gz`) on Unix, and ZIP file on Windows.
You can specify as many formats as you like using the :option:`!--formats`
option, for example::
python setup.py sdist --formats=gztar,zip
to create a gzipped tarball and a zip file. The available formats are:
+-----------+-------------------------+---------+
| Format | Description | Notes |
+===========+=========================+=========+
| ``zip`` | zip file (:file:`.zip`) | (1),(3) |
+-----------+-------------------------+---------+
| ``gztar`` | gzip'ed tar file | \(2) |
| | (:file:`.tar.gz`) | |
+-----------+-------------------------+---------+
| ``bztar`` | bzip2'ed tar file | |
| | (:file:`.tar.bz2`) | |
+-----------+-------------------------+---------+
| ``xztar`` | xz'ed tar file | |
| | (:file:`.tar.xz`) | |
+-----------+-------------------------+---------+
| ``ztar`` | compressed tar file | \(4) |
| | (:file:`.tar.Z`) | |
+-----------+-------------------------+---------+
| ``tar`` | tar file (:file:`.tar`) | |
+-----------+-------------------------+---------+
.. versionchanged:: 3.5
Added support for the ``xztar`` format.
Notes:
(1)
default on Windows
(2)
default on Unix
(3)
requires either external :program:`zip` utility or :mod:`zipfile` module (part
of the standard Python library since Python 1.6)
(4)
requires the :program:`compress` program. Notice that this format is now
pending for deprecation and will be removed in the future versions of Python.
When using any ``tar`` format (``gztar``, ``bztar``, ``xztar``, ``ztar`` or
``tar``), under Unix you can specify the ``owner`` and ``group`` names
that will be set for each member of the archive.
For example, if you want all files of the archive to be owned by root::
python setup.py sdist --owner=root --group=root
.. _manifest:
Specifying the files to distribute
==================================
If you don't supply an explicit list of files (or instructions on how to
generate one), the :command:`sdist` command puts a minimal default set into the
source distribution:
* all Python source files implied by the ``py_modules`` and
``packages`` options
* all C source files mentioned in the ``ext_modules`` or
``libraries`` options
.. XXX getting C library sources currently broken---no
:meth:`get_source_files` method in :file:`build_clib.py`!
* scripts identified by the ``scripts`` option
See :ref:`distutils-installing-scripts`.
* anything that looks like a test script: :file:`test/test\*.py` (currently, the
Distutils don't do anything with test scripts except include them in source
distributions, but in the future there will be a standard for testing Python
module distributions)
* Any of the standard README files (:file:`README`, :file:`README.txt`,
or :file:`README.rst`), :file:`setup.py` (or whatever you called your setup
script), and :file:`setup.cfg`.
* all files that matches the ``package_data`` metadata.
See :ref:`distutils-installing-package-data`.
* all files that matches the ``data_files`` metadata.
See :ref:`distutils-additional-files`.
Sometimes this is enough, but usually you will want to specify additional files
to distribute. The typical way to do this is to write a *manifest template*,
called :file:`MANIFEST.in` by default. The manifest template is just a list of
instructions for how to generate your manifest file, :file:`MANIFEST`, which is
the exact list of files to include in your source distribution. The
:command:`sdist` command processes this template and generates a manifest based
on its instructions and what it finds in the filesystem.
If you prefer to roll your own manifest file, the format is simple: one filename
per line, regular files (or symlinks to them) only. If you do supply your own
:file:`MANIFEST`, you must specify everything: the default set of files
described above does not apply in this case.
.. versionchanged:: 3.1
An existing generated :file:`MANIFEST` will be regenerated without
:command:`sdist` comparing its modification time to the one of
:file:`MANIFEST.in` or :file:`setup.py`.
.. versionchanged:: 3.1.3
:file:`MANIFEST` files start with a comment indicating they are generated.
Files without this comment are not overwritten or removed.
.. versionchanged:: 3.2.2
:command:`sdist` will read a :file:`MANIFEST` file if no :file:`MANIFEST.in`
exists, like it used to do.
.. versionchanged:: 3.7
:file:`README.rst` is now included in the list of distutils standard READMEs.
The manifest template has one command per line, where each command specifies a
set of files to include or exclude from the source distribution. For an
example, again we turn to the Distutils' own manifest template:
.. code-block:: none
include *.txt
recursive-include examples *.txt *.py
prune examples/sample?/build
The meanings should be fairly clear: include all files in the distribution root
matching :file:`\*.txt`, all files anywhere under the :file:`examples` directory
matching :file:`\*.txt` or :file:`\*.py`, and exclude all directories matching
:file:`examples/sample?/build`. All of this is done *after* the standard
include set, so you can exclude files from the standard set with explicit
instructions in the manifest template. (Or, you can use the
:option:`!--no-defaults` option to disable the standard set entirely.) There are
several other commands available in the manifest template mini-language; see
section :ref:`sdist-cmd`.
The order of commands in the manifest template matters: initially, we have the
list of default files as described above, and each command in the template adds
to or removes from that list of files. Once we have fully processed the
manifest template, we remove files that should not be included in the source
distribution:
* all files in the Distutils "build" tree (default :file:`build/`)
* all files in directories named :file:`RCS`, :file:`CVS`, :file:`.svn`,
:file:`.hg`, :file:`.git`, :file:`.bzr` or :file:`_darcs`
Now we have our complete list of files, which is written to the manifest for
future reference, and then used to build the source distribution archive(s).
You can disable the default set of included files with the
:option:`!--no-defaults` option, and you can disable the standard exclude set
with :option:`!--no-prune`.
Following the Distutils' own manifest template, let's trace how the
:command:`sdist` command builds the list of files to include in the Distutils
source distribution:
#. include all Python source files in the :file:`distutils` and
:file:`distutils/command` subdirectories (because packages corresponding to
those two directories were mentioned in the ``packages`` option in the
setup script---see section :ref:`setup-script`)
#. include :file:`README.txt`, :file:`setup.py`, and :file:`setup.cfg` (standard
files)
#. include :file:`test/test\*.py` (standard files)
#. include :file:`\*.txt` in the distribution root (this will find
:file:`README.txt` a second time, but such redundancies are weeded out later)
#. include anything matching :file:`\*.txt` or :file:`\*.py` in the sub-tree
under :file:`examples`,
#. exclude all files in the sub-trees starting at directories matching
:file:`examples/sample?/build`\ ---this may exclude files included by the
previous two steps, so it's important that the ``prune`` command in the manifest
template comes after the ``recursive-include`` command
#. exclude the entire :file:`build` tree, and any :file:`RCS`, :file:`CVS`,
:file:`.svn`, :file:`.hg`, :file:`.git`, :file:`.bzr` and :file:`_darcs`
directories
Just like in the setup script, file and directory names in the manifest template
should always be slash-separated; the Distutils will take care of converting
them to the standard representation on your platform. That way, the manifest
template is portable across operating systems.
.. _manifest-options:
Manifest-related options
========================
The normal course of operations for the :command:`sdist` command is as follows:
* if the manifest file (:file:`MANIFEST` by default) exists and the first line
does not have a comment indicating it is generated from :file:`MANIFEST.in`,
then it is used as is, unaltered
* if the manifest file doesn't exist or has been previously automatically
generated, read :file:`MANIFEST.in` and create the manifest
* if neither :file:`MANIFEST` nor :file:`MANIFEST.in` exist, create a manifest
with just the default file set
* use the list of files now in :file:`MANIFEST` (either just generated or read
in) to create the source distribution archive(s)
There are a couple of options that modify this behaviour. First, use the
:option:`!--no-defaults` and :option:`!--no-prune` to disable the standard
"include" and "exclude" sets.
Second, you might just want to (re)generate the manifest, but not create a source
distribution::
python setup.py sdist --manifest-only
:option:`!-o` is a shortcut for :option:`!--manifest-only`.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils/uploading.rst 0000644 0001751 0000173 00000000342 14467657412 023241 0 ustar 00runner docker :orphan:
***************************************
Uploading Packages to the Package Index
***************************************
References to up to date PyPI documentation can be found at
:ref:`publishing-python-packages`.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/distutils-legacy.rst 0000644 0001751 0000173 00000004515 14467657412 022527 0 ustar 00runner docker Porting from Distutils
======================
Setuptools and the PyPA have a `stated goal `_ to make Setuptools the reference API for distutils.
Since the 60.0.0 release, Setuptools includes a local, vendored copy of distutils (from late copies of CPython) that is enabled by default. To disable the use of this copy of distutils when invoking setuptools, set the environment variable:
SETUPTOOLS_USE_DISTUTILS=stdlib
.. warning::
Please note that this also affects how ``distutils.cfg`` files inside stdlib's ``distutils``
package directory are processed.
Unless ``SETUPTOOLS_USE_DISTUTILS=stdlib``, they will have no effect on the build process.
You can still use a global user config file, ``~/.pydistutils.cfg`` (POSIX) or ``%USERPROFILE%/pydistutils.cfg`` (Windows),
or use the environment variable :ref:`DIST_EXTRA_CONFIG ` to point to another
supplementary configuration file.
Prefer Setuptools
-----------------
As Distutils is deprecated, any usage of functions or objects from distutils is similarly discouraged, and Setuptools aims to replace or deprecate all such uses. This section describes the recommended replacements.
``distutils.core.setup`` → ``setuptools.setup``
``distutils.cmd.Command`` or ``distutils.core.Command`` → ``setuptools.Command``
``distutils.command.{build_clib,build_ext,build_py,sdist}`` → ``setuptools.command.*``
``distutils.log`` → :mod:`logging` (standard library)
``distutils.version.*`` → :doc:`packaging.version.* `
``distutils.errors.*`` → ``setuptools.errors.*`` [#errors]_
Migration advice is also provided by :pep:`PEP 632 <632#migration-advice>`.
If a project relies on uses of ``distutils`` that do not have a suitable replacement above, please search the `Setuptools issue tracker `_ and file a request, describing the use-case so that Setuptools' maintainers can investigate. Please provide enough detail to help the maintainers understand how distutils is used, what value it provides, and why that behavior should be supported.
.. [#errors] Please notice errors related to the command line usage of
``setup.py``, such as ``DistutilsArgError``, are intentionally not exposed
by setuptools, since this is considered a deprecated practice.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/easy_install.rst 0000644 0001751 0000173 00000145452 14467657412 021736 0 ustar 00runner docker ============
Easy Install
============
.. warning::
Easy Install is deprecated. Do not use it. Instead use pip. If
you think you need Easy Install, please reach out to the PyPA
team (a ticket to pip or setuptools is fine), describing your
use-case.
Easy Install is a python module (``easy_install``) bundled with ``setuptools``
that lets you automatically download, build, install, and manage Python
packages.
Please share your experiences with us! If you encounter difficulty installing
a package, please contact us via the `distutils mailing list
`_. (Note: please DO NOT send
private email directly to the author of setuptools; it will be discarded. The
mailing list is a searchable archive of previously-asked and answered
questions; you should begin your research there before reporting something as a
bug -- and then do so via list discussion first.)
(Also, if you'd like to learn about how you can use ``setuptools`` to make your
own packages work better with EasyInstall, or provide EasyInstall-like features
without requiring your users to use EasyInstall directly, you'll probably want
to check out the full documentation as well.)
Using "Easy Install"
====================
.. _installation instructions:
Installing "Easy Install"
-------------------------
Please see the :pypi:`setuptools` on the package index
for download links and basic installation instructions for each of the
supported platforms.
You will need at least Python 3.5 or 2.7. An ``easy_install`` script will be
installed in the normal location for Python scripts on your platform.
Note that the instructions on the setuptools PyPI page assume that you are
are installing to Python's primary ``site-packages`` directory. If this is
not the case, you should consult the section below on `Custom Installation
Locations`_ before installing. (And, on Windows, you should not use the
``.exe`` installer when installing to an alternate location.)
Note that ``easy_install`` normally works by downloading files from the
internet. If you are behind an NTLM-based firewall that prevents Python
programs from accessing the net directly, you may wish to first install and use
the `APS proxy server `_, which lets you get past such
firewalls in the same way that your web browser(s) do.
(Alternately, if you do not wish easy_install to actually download anything, you
can restrict it from doing so with the ``--allow-hosts`` option; see the
sections on `restricting downloads with --allow-hosts`_ and `command-line
options`_ for more details.)
Troubleshooting
~~~~~~~~~~~~~~~
If EasyInstall/setuptools appears to install correctly, and you can run the
``easy_install`` command but it fails with an ``ImportError``, the most likely
cause is that you installed to a location other than ``site-packages``,
without taking any of the steps described in the `Custom Installation
Locations`_ section below. Please see that section and follow the steps to
make sure that your custom location will work correctly. Then re-install.
Similarly, if you can run ``easy_install``, and it appears to be installing
packages, but then you can't import them, the most likely issue is that you
installed EasyInstall correctly but are using it to install packages to a
non-standard location that hasn't been properly prepared. Again, see the
section on `Custom Installation Locations`_ for more details.
Windows Notes
~~~~~~~~~~~~~
Installing setuptools will provide an ``easy_install`` command according to
the techniques described in `Executables and Launchers`_. If the
``easy_install`` command is not available after installation, that section
provides details on how to configure Windows to make the commands available.
Downloading and Installing a Package
------------------------------------
For basic use of ``easy_install``, you need only supply the filename or URL of
a source distribution or .egg file (`Python Egg`__).
__ http://peak.telecommunity.com/DevCenter/PythonEggs
**Example 1**. Install a package by name, searching PyPI for the latest
version, and automatically downloading, building, and installing it::
easy_install SQLObject
**Example 2**. Install or upgrade a package by name and version by finding
links on a given "download page"::
easy_install -f http://pythonpaste.org/package_index.html SQLObject
**Example 3**. Download a source distribution from a specified URL,
automatically building and installing it::
easy_install http://example.com/path/to/MyPackage-1.2.3.tgz
**Example 4**. Install an already-downloaded .egg file::
easy_install /my_downloads/OtherPackage-3.2.1-py2.3.egg
**Example 5**. Upgrade an already-installed package to the latest version
listed on PyPI::
easy_install --upgrade PyProtocols
**Example 6**. Install a source distribution that's already downloaded and
extracted in the current directory (New in 0.5a9)::
easy_install .
**Example 7**. (New in 0.6a1) Find a source distribution or Subversion
checkout URL for a package, and extract it or check it out to
``~/projects/sqlobject`` (the name will always be in all-lowercase), where it
can be examined or edited. (The package will not be installed, but it can
easily be installed with ``easy_install ~/projects/sqlobject``. See `Editing
and Viewing Source Packages`_ below for more info.)::
easy_install --editable --build-directory ~/projects SQLObject
**Example 7**. (New in 0.6.11) Install a distribution within your home dir::
easy_install --user SQLAlchemy
Easy Install accepts URLs, filenames, PyPI package names (i.e., ``distutils``
"distribution" names), and package+version specifiers. In each case, it will
attempt to locate the latest available version that meets your criteria.
When downloading or processing downloaded files, Easy Install recognizes
distutils source distribution files with extensions of .tgz, .tar, .tar.gz,
.tar.bz2, or .zip. And of course it handles already-built .egg
distributions as well as ``.win32.exe`` installers built using distutils.
By default, packages are installed to the running Python installation's
``site-packages`` directory, unless you provide the ``-d`` or ``--install-dir``
option to specify an alternative directory, or specify an alternate location
using distutils configuration files. (See `Configuration Files`_, below.)
By default, any scripts included with the package are installed to the running
Python installation's standard script installation location. However, if you
specify an installation directory via the command line or a config file, then
the default directory for installing scripts will be the same as the package
installation directory, to ensure that the script will have access to the
installed package. You can override this using the ``-s`` or ``--script-dir``
option.
Installed packages are added to an ``easy-install.pth`` file in the install
directory, so that Python will always use the most-recently-installed version
of the package. If you would like to be able to select which version to use at
runtime, you should use the ``-m`` or ``--multi-version`` option.
Upgrading a Package
-------------------
You don't need to do anything special to upgrade a package: just install the
new version, either by requesting a specific version, e.g.::
easy_install "SomePackage==2.0"
a version greater than the one you have now::
easy_install "SomePackage>2.0"
using the upgrade flag, to find the latest available version on PyPI::
easy_install --upgrade SomePackage
or by using a download page, direct download URL, or package filename::
easy_install -f http://example.com/downloads ExamplePackage
easy_install http://example.com/downloads/ExamplePackage-2.0-py2.4.egg
easy_install my_downloads/ExamplePackage-2.0.tgz
If you're using ``-m`` or ``--multi-version`` , using the ``require()``
function at runtime automatically selects the newest installed version of a
package that meets your version criteria. So, installing a newer version is
the only step needed to upgrade such packages.
If you're installing to a directory on PYTHONPATH, or a configured "site"
directory (and not using ``-m``), installing a package automatically replaces
any previous version in the ``easy-install.pth`` file, so that Python will
import the most-recently installed version by default. So, again, installing
the newer version is the only upgrade step needed.
If you haven't suppressed script installation (using ``--exclude-scripts`` or
``-x``), then the upgraded version's scripts will be installed, and they will
be automatically patched to ``require()`` the corresponding version of the
package, so that you can use them even if they are installed in multi-version
mode.
``easy_install`` never actually deletes packages (unless you're installing a
package with the same name and version number as an existing package), so if
you want to get rid of older versions of a package, please see `Uninstalling
Packages`_, below.
Changing the Active Version
---------------------------
If you've upgraded a package, but need to revert to a previously-installed
version, you can do so like this::
easy_install PackageName==1.2.3
Where ``1.2.3`` is replaced by the exact version number you wish to switch to.
If a package matching the requested name and version is not already installed
in a directory on ``sys.path``, it will be located via PyPI and installed.
If you'd like to switch to the latest installed version of ``PackageName``, you
can do so like this::
easy_install PackageName
This will activate the latest installed version. (Note: if you have set any
``find_links`` via distutils configuration files, those download pages will be
checked for the latest available version of the package, and it will be
downloaded and installed if it is newer than your current version.)
Note that changing the active version of a package will install the newly
active version's scripts, unless the ``--exclude-scripts`` or ``-x`` option is
specified.
Uninstalling Packages
---------------------
If you have replaced a package with another version, then you can just delete
the package(s) you don't need by deleting the PackageName-versioninfo.egg file
or directory (found in the installation directory).
If you want to delete the currently installed version of a package (or all
versions of a package), you should first run::
easy_install -m PackageName
This will ensure that Python doesn't continue to search for a package you're
planning to remove. After you've done this, you can safely delete the .egg
files or directories, along with any scripts you wish to remove.
Managing Scripts
----------------
Whenever you install, upgrade, or change versions of a package, EasyInstall
automatically installs the scripts for the selected package version, unless
you tell it not to with ``-x`` or ``--exclude-scripts``. If any scripts in
the script directory have the same name, they are overwritten.
Thus, you do not normally need to manually delete scripts for older versions of
a package, unless the newer version of the package does not include a script
of the same name. However, if you are completely uninstalling a package, you
may wish to manually delete its scripts.
EasyInstall's default behavior means that you can normally only run scripts
from one version of a package at a time. If you want to keep multiple versions
of a script available, however, you can simply use the ``--multi-version`` or
``-m`` option, and rename the scripts that EasyInstall creates. This works
because EasyInstall installs scripts as short code stubs that ``require()`` the
matching version of the package the script came from, so renaming the script
has no effect on what it executes.
For example, suppose you want to use two versions of the ``rst2html`` tool
provided by the `docutils `_ package. You might
first install one version::
easy_install -m docutils==0.3.9
then rename the ``rst2html.py`` to ``r2h_039``, and install another version::
easy_install -m docutils==0.3.10
This will create another ``rst2html.py`` script, this one using docutils
version 0.3.10 instead of 0.3.9. You now have two scripts, each using a
different version of the package. (Notice that we used ``-m`` for both
installations, so that Python won't lock us out of using anything but the most
recently-installed version of the package.)
Executables and Launchers
-------------------------
On Unix systems, scripts are installed with as natural files with a "#!"
header and no extension and they launch under the Python version indicated in
the header.
On Windows, there is no mechanism to "execute" files without extensions, so
EasyInstall provides two techniques to mirror the Unix behavior. The behavior
is indicated by the SETUPTOOLS_LAUNCHER environment variable, which may be
"executable" (default) or "natural".
Regardless of the technique used, the script(s) will be installed to a Scripts
directory (by default in the Python installation directory). It is recommended
for EasyInstall that you ensure this directory is in the PATH environment
variable. The easiest way to ensure the Scripts directory is in the PATH is
to run ``Tools\Scripts\win_add2path.py`` from the Python directory.
Note that instead of changing your ``PATH`` to include the Python scripts
directory, you can also retarget the installation location for scripts so they
go on a directory that's already on the ``PATH``. For more information see
`Command-Line Options`_ and `Configuration Files`_. During installation,
pass command line options (such as ``--script-dir``) to control where
scripts will be installed.
Windows Executable Launcher
~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the "executable" launcher is used, EasyInstall will create a '.exe'
launcher of the same name beside each installed script (including
``easy_install`` itself). These small .exe files launch the script of the
same name using the Python version indicated in the '#!' header.
This behavior is currently default. To force
the use of executable launchers, set ``SETUPTOOLS_LAUNCHER`` to "executable".
Natural Script Launcher
~~~~~~~~~~~~~~~~~~~~~~~
EasyInstall also supports deferring to an external launcher such as
`pylauncher `_ for launching scripts.
Enable this experimental functionality by setting the
``SETUPTOOLS_LAUNCHER`` environment variable to "natural". EasyInstall will
then install scripts as simple
scripts with a .pya (or .pyw) extension appended. If these extensions are
associated with the pylauncher and listed in the PATHEXT environment variable,
these scripts can then be invoked simply and directly just like any other
executable. This behavior may become default in a future version.
EasyInstall uses the .pya extension instead of simply
the typical '.py' extension. This distinct extension is necessary to prevent
Python
from treating the scripts as importable modules (where name conflicts exist).
Current releases of pylauncher do not yet associate with .pya files by
default, but future versions should do so.
Tips & Techniques
-----------------
Multiple Python Versions
~~~~~~~~~~~~~~~~~~~~~~~~
EasyInstall installs itself under two names:
``easy_install`` and ``easy_install-N.N``, where ``N.N`` is the Python version
used to install it. Thus, if you install EasyInstall for both Python 3.2 and
2.7, you can use the ``easy_install-3.2`` or ``easy_install-2.7`` scripts to
install packages for the respective Python version.
Setuptools also supplies easy_install as a runnable module which may be
invoked using ``python -m easy_install`` for any Python with Setuptools
installed.
Restricting Downloads with ``--allow-hosts``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can use the ``--allow-hosts`` (``-H``) option to restrict what domains
EasyInstall will look for links and downloads on. ``--allow-hosts=None``
prevents downloading altogether. You can also use wildcards, for example
to restrict downloading to hosts in your own intranet. See the section below
on `Command-Line Options`_ for more details on the ``--allow-hosts`` option.
By default, there are no host restrictions in effect, but you can change this
default by editing the appropriate `configuration files`_ and adding:
.. code-block:: ini
[easy_install]
allow_hosts = *.myintranet.example.com,*.python.org
The above example would then allow downloads only from hosts in the
``python.org`` and ``myintranet.example.com`` domains, unless overridden on the
command line.
Installing on Un-networked Machines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Just copy the eggs or source packages you need to a directory on the target
machine, then use the ``-f`` or ``--find-links`` option to specify that
directory's location. For example::
easy_install -H None -f somedir SomePackage
will attempt to install SomePackage using only eggs and source packages found
in ``somedir`` and disallowing all remote access. You should of course make
sure you have all of SomePackage's dependencies available in somedir.
If you have another machine of the same operating system and library versions
(or if the packages aren't platform-specific), you can create the directory of
eggs using a command like this::
easy_install -zmaxd somedir SomePackage
This will tell EasyInstall to put zipped eggs or source packages for
SomePackage and all its dependencies into ``somedir``, without creating any
scripts or .pth files. You can then copy the contents of ``somedir`` to the
target machine. (``-z`` means zipped eggs, ``-m`` means multi-version, which
prevents .pth files from being used, ``-a`` means to copy all the eggs needed,
even if they're installed elsewhere on the machine, and ``-d`` indicates the
directory to place the eggs in.)
You can also build the eggs from local development packages that were installed
with the ``setup.py develop`` command, by including the ``-l`` option, e.g.::
easy_install -zmaxld somedir SomePackage
This will use locally-available source distributions to build the eggs.
Packaging Others' Projects As Eggs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Need to distribute a package that isn't published in egg form? You can use
EasyInstall to build eggs for a project. You'll want to use the ``--zip-ok``,
``--exclude-scripts``, and possibly ``--no-deps`` options (``-z``, ``-x`` and
``-N``, respectively). Use ``-d`` or ``--install-dir`` to specify the location
where you'd like the eggs placed. By placing them in a directory that is
published to the web, you can then make the eggs available for download, either
in an intranet or to the internet at large.
If someone distributes a package in the form of a single ``.py`` file, you can
wrap it in an egg by tacking an ``#egg=name-version`` suffix on the file's URL.
So, something like this::
easy_install -f "http://some.example.com/downloads/foo.py#egg=foo-1.0" foo
will install the package as an egg, and this::
easy_install -zmaxd. \
-f "http://some.example.com/downloads/foo.py#egg=foo-1.0" foo
will create a ``.egg`` file in the current directory.
Creating your own Package Index
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In addition to local directories and the Python Package Index, EasyInstall can
find download links on most any web page whose URL is given to the ``-f``
(``--find-links``) option. In the simplest case, you can simply have a web
page with links to eggs or Python source packages, even an automatically
generated directory listing (such as the Apache web server provides).
If you are setting up an intranet site for package downloads, you may want to
configure the target machines to use your download site by default, adding
something like this to their `configuration files`_:
.. code-block:: ini
[easy_install]
find_links = http://mypackages.example.com/somedir/
http://turbogears.org/download/
http://peak.telecommunity.com/dist/
As you can see, you can list multiple URLs separated by whitespace, continuing
on multiple lines if necessary (as long as the subsequent lines are indented.
If you are more ambitious, you can also create an entirely custom package index
or PyPI mirror. See the ``--index-url`` option under `Command-Line Options`_,
below, and also the section on `Package Index "API"`_.
Password-Protected Sites
------------------------
If a site you want to download from is password-protected using HTTP "Basic"
authentication, you can specify your credentials in the URL, like so::
http://some_userid:some_password@some.example.com/some_path/
You can do this with both index page URLs and direct download URLs. As long
as any HTML pages read by easy_install use *relative* links to point to the
downloads, the same user ID and password will be used to do the downloading.
Using .pypirc Credentials
-------------------------
In additional to supplying credentials in the URL, ``easy_install`` will also
honor credentials if present in the .pypirc file. Teams maintaining a private
repository of packages may already have defined access credentials for
uploading packages according to the distutils documentation. ``easy_install``
will attempt to honor those if present. Refer to the distutils documentation
for Python 2.5 or later for details on the syntax.
Controlling Build Options
~~~~~~~~~~~~~~~~~~~~~~~~~
EasyInstall respects standard distutils `Configuration Files`_, so you can use
them to configure build options for packages that it installs from source. For
example, if you are on Windows using the MinGW compiler, you can configure the
default compiler by putting something like this:
.. code-block:: ini
[build]
compiler = mingw32
into the appropriate distutils configuration file. In fact, since this is just
normal distutils configuration, it will affect any builds using that config
file, not just ones done by EasyInstall. For example, if you add those lines
to ``distutils.cfg`` in the ``distutils`` package directory, it will be the
default compiler for *all* packages you build. See `Configuration Files`_
below for a list of the standard configuration file locations, and links to
more documentation on using distutils configuration files.
Editing and Viewing Source Packages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sometimes a package's source distribution contains additional documentation,
examples, configuration files, etc., that are not part of its actual code. If
you want to be able to examine these files, you can use the ``--editable``
option to EasyInstall, and EasyInstall will look for a source distribution
or Subversion URL for the package, then download and extract it or check it out
as a subdirectory of the ``--build-directory`` you specify. If you then wish
to install the package after editing or configuring it, you can do so by
rerunning EasyInstall with that directory as the target.
Note that using ``--editable`` stops EasyInstall from actually building or
installing the package; it just finds, obtains, and possibly unpacks it for
you. This allows you to make changes to the package if necessary, and to
either install it in development mode using ``setup.py develop`` (if the
package uses setuptools, that is), or by running ``easy_install projectdir``
(where ``projectdir`` is the subdirectory EasyInstall created for the
downloaded package.
In order to use ``--editable`` (``-e`` for short), you *must* also supply a
``--build-directory`` (``-b`` for short). The project will be placed in a
subdirectory of the build directory. The subdirectory will have the same
name as the project itself, but in all-lowercase. If a file or directory of
that name already exists, EasyInstall will print an error message and exit.
Also, when using ``--editable``, you cannot use URLs or filenames as arguments.
You *must* specify project names (and optional version requirements) so that
EasyInstall knows what directory name(s) to create. If you need to force
EasyInstall to use a particular URL or filename, you should specify it as a
``--find-links`` item (``-f`` for short), and then also specify
the project name, e.g.::
easy_install -eb ~/projects \
-fhttp://prdownloads.sourceforge.net/ctypes/ctypes-0.9.6.tar.gz?download \
ctypes==0.9.6
Dealing with Installation Conflicts
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(NOTE: As of 0.6a11, this section is obsolete; it is retained here only so that
people using older versions of EasyInstall can consult it. As of version
0.6a11, installation conflicts are handled automatically without deleting the
old or system-installed packages, and without ignoring the issue. Instead,
eggs are automatically shifted to the front of ``sys.path`` using special
code added to the ``easy-install.pth`` file. So, if you are using version
0.6a11 or better of setuptools, you do not need to worry about conflicts,
and the following issues do not apply to you.)
EasyInstall installs distributions in a "managed" way, such that each
distribution can be independently activated or deactivated on ``sys.path``.
However, packages that were not installed by EasyInstall are "unmanaged",
in that they usually live all in one directory and cannot be independently
activated or deactivated.
As a result, if you are using EasyInstall to upgrade an existing package, or
to install a package with the same name as an existing package, EasyInstall
will warn you of the conflict. (This is an improvement over ``setup.py
install``, because the ``distutils`` just install new packages on top of old
ones, possibly combining two unrelated packages or leaving behind modules that
have been deleted in the newer version of the package.)
EasyInstall will stop the installation if it detects a conflict
between an existing, "unmanaged" package, and a module or package in any of
the distributions you're installing. It will display a list of all of the
existing files and directories that would need to be deleted for the new
package to be able to function correctly. To proceed, you must manually
delete these conflicting files and directories and re-run EasyInstall.
Of course, once you've replaced all of your existing "unmanaged" packages with
versions managed by EasyInstall, you won't have any more conflicts to worry
about!
Compressed Installation
~~~~~~~~~~~~~~~~~~~~~~~
EasyInstall tries to install packages in zipped form, if it can. Zipping
packages can improve Python's overall import performance if you're not using
the ``--multi-version`` option, because Python processes zipfile entries on
``sys.path`` much faster than it does directories.
As of version 0.5a9, EasyInstall analyzes packages to determine whether they
can be safely installed as a zipfile, and then acts on its analysis. (Previous
versions would not install a package as a zipfile unless you used the
``--zip-ok`` option.)
The current analysis approach is fairly conservative; it currently looks for:
* Any use of the ``__file__`` or ``__path__`` variables (which should be
replaced with ``pkg_resources`` API calls)
* Possible use of ``inspect`` functions that expect to manipulate source files
(e.g. ``inspect.getsource()``)
* Top-level modules that might be scripts used with ``python -m`` (Python 2.4)
If any of the above are found in the package being installed, EasyInstall will
assume that the package cannot be safely run from a zipfile, and unzip it to
a directory instead. You can override this analysis with the ``-zip-ok`` flag,
which will tell EasyInstall to install the package as a zipfile anyway. Or,
you can use the ``--always-unzip`` flag, in which case EasyInstall will always
unzip, even if its analysis says the package is safe to run as a zipfile.
Normally, however, it is simplest to let EasyInstall handle the determination
of whether to zip or unzip, and only specify overrides when needed to work
around a problem. If you find you need to override EasyInstall's guesses, you
may want to contact the package author and the EasyInstall maintainers, so that
they can make appropriate changes in future versions.
(Note: If a package uses ``setuptools`` in its setup script, the package author
has the option to declare the package safe or unsafe for zipped usage via the
``zip_safe`` argument to ``setup()``. If the package author makes such a
declaration, EasyInstall believes the package's author and does not perform its
own analysis. However, your command-line option, if any, will still override
the package author's choice.)
Reference Manual
================
Configuration Files
-------------------
(New in 0.4a2)
You may specify default options for EasyInstall using the standard
distutils configuration files, under the command heading ``easy_install``.
EasyInstall will look first for a ``setup.cfg`` file in the current directory,
then a ``~/.pydistutils.cfg`` or ``$HOME\\pydistutils.cfg`` (on Unix-like OSes
and Windows, respectively), and finally a ``distutils.cfg`` file in the
``distutils`` package directory. Here's a simple example:
.. code-block:: ini
[easy_install]
# set the default location to install packages
install_dir = /home/me/lib/python
# Notice that indentation can be used to continue an option
# value; this is especially useful for the "--find-links"
# option, which tells easy_install to use download links on
# these pages before consulting PyPI:
#
find_links = http://sqlobject.org/
http://peak.telecommunity.com/dist/
In addition to accepting configuration for its own options under
``[easy_install]``, EasyInstall also respects defaults specified for other
distutils commands. For example, if you don't set an ``install_dir`` for
``[easy_install]``, but *have* set an ``install_lib`` for the ``[install]``
command, this will become EasyInstall's default installation directory. Thus,
if you are already using distutils configuration files to set default install
locations, build options, etc., EasyInstall will respect your existing settings
until and unless you override them explicitly in an ``[easy_install]`` section.
For more information, see also the current Python documentation on the `use and
location of distutils configuration files `_.
Notice that ``easy_install`` will use the ``setup.cfg`` from the current
working directory only if it was triggered from ``setup.py`` through the
``install_requires`` option. The standalone command will not use that file.
Command-Line Options
--------------------
``--zip-ok, -z``
Install all packages as zip files, even if they are marked as unsafe for
running as a zipfile. This can be useful when EasyInstall's analysis
of a non-setuptools package is too conservative, but keep in mind that
the package may not work correctly. (Changed in 0.5a9; previously this
option was required in order for zipped installation to happen at all.)
``--always-unzip, -Z``
Don't install any packages as zip files, even if the packages are marked
as safe for running as a zipfile. This can be useful if a package does
something unsafe, but not in a way that EasyInstall can easily detect.
EasyInstall's default analysis is currently very conservative, however, so
you should only use this option if you've had problems with a particular
package, and *after* reporting the problem to the package's maintainer and
to the EasyInstall maintainers.
(Note: the ``-z/-Z`` options only affect the installation of newly-built
or downloaded packages that are not already installed in the target
directory; if you want to convert an existing installed version from
zipped to unzipped or vice versa, you'll need to delete the existing
version first, and re-run EasyInstall.)
``--multi-version, -m``
"Multi-version" mode. Specifying this option prevents ``easy_install`` from
adding an ``easy-install.pth`` entry for the package being installed, and
if an entry for any version the package already exists, it will be removed
upon successful installation. In multi-version mode, no specific version of
the package is available for importing, unless you use
``pkg_resources.require()`` to put it on ``sys.path``. This can be as
simple as::
from pkg_resources import require
require("SomePackage", "OtherPackage", "MyPackage")
which will put the latest installed version of the specified packages on
``sys.path`` for you. (For more advanced uses, like selecting specific
versions and enabling optional dependencies, see the ``pkg_resources`` API
doc.)
Changed in 0.6a10: this option is no longer silently enabled when
installing to a non-PYTHONPATH, non-"site" directory. You must always
explicitly use this option if you want it to be active.
``--upgrade, -U`` (New in 0.5a4)
By default, EasyInstall only searches online if a project/version
requirement can't be met by distributions already installed
on sys.path or the installation directory. However, if you supply the
``--upgrade`` or ``-U`` flag, EasyInstall will always check the package
index and ``--find-links`` URLs before selecting a version to install. In
this way, you can force EasyInstall to use the latest available version of
any package it installs (subject to any version requirements that might
exclude such later versions).
``--install-dir=DIR, -d DIR``
Set the installation directory. It is up to you to ensure that this
directory is on ``sys.path`` at runtime, and to use
``pkg_resources.require()`` to enable the installed package(s) that you
need.
(New in 0.4a2) If this option is not directly specified on the command line
or in a distutils configuration file, the distutils default installation
location is used. Normally, this would be the ``site-packages`` directory,
but if you are using distutils configuration files, setting things like
``prefix`` or ``install_lib``, then those settings are taken into
account when computing the default installation directory, as is the
``--prefix`` option.
``--script-dir=DIR, -s DIR``
Set the script installation directory. If you don't supply this option
(via the command line or a configuration file), but you *have* supplied
an ``--install-dir`` (via command line or config file), then this option
defaults to the same directory, so that the scripts will be able to find
their associated package installation. Otherwise, this setting defaults
to the location where the distutils would normally install scripts, taking
any distutils configuration file settings into account.
``--exclude-scripts, -x``
Don't install scripts. This is useful if you need to install multiple
versions of a package, but do not want to reset the version that will be
run by scripts that are already installed.
``--user`` (New in 0.6.11)
Use the user-site-packages as specified in :pep:`370`
instead of the global site-packages.
``--always-copy, -a`` (New in 0.5a4)
Copy all needed distributions to the installation directory, even if they
are already present in a directory on sys.path. In older versions of
EasyInstall, this was the default behavior, but now you must explicitly
request it. By default, EasyInstall will no longer copy such distributions
from other sys.path directories to the installation directory, unless you
explicitly gave the distribution's filename on the command line.
Note that as of 0.6a10, using this option excludes "system" and
"development" eggs from consideration because they can't be reliably
copied. This may cause EasyInstall to choose an older version of a package
than what you expected, or it may cause downloading and installation of a
fresh copy of something that's already installed. You will see warning
messages for any eggs that EasyInstall skips, before it falls back to an
older version or attempts to download a fresh copy.
``--find-links=URLS_OR_FILENAMES, -f URLS_OR_FILENAMES``
Scan the specified "download pages" or directories for direct links to eggs
or other distributions. Any existing file or directory names or direct
download URLs are immediately added to EasyInstall's search cache, and any
indirect URLs (ones that don't point to eggs or other recognized archive
formats) are added to a list of additional places to search for download
links. As soon as EasyInstall has to go online to find a package (either
because it doesn't exist locally, or because ``--upgrade`` or ``-U`` was
used), the specified URLs will be downloaded and scanned for additional
direct links.
Eggs and archives found by way of ``--find-links`` are only downloaded if
they are needed to meet a requirement specified on the command line; links
to unneeded packages are ignored.
If all requested packages can be found using links on the specified
download pages, the Python Package Index will not be consulted unless you
also specified the ``--upgrade`` or ``-U`` option.
(Note: if you want to refer to a local HTML file containing links, you must
use a ``file:`` URL, as filenames that do not refer to a directory, egg, or
archive are ignored.)
You may specify multiple URLs or file/directory names with this option,
separated by whitespace. Note that on the command line, you will probably
have to surround the URL list with quotes, so that it is recognized as a
single option value. You can also specify URLs in a configuration file;
see `Configuration Files`_, above.
Changed in 0.6a10: previously all URLs and directories passed to this
option were scanned as early as possible, but from 0.6a10 on, only
directories and direct archive links are scanned immediately; URLs are not
retrieved unless a package search was already going to go online due to a
package not being available locally, or due to the use of the ``--update``
or ``-U`` option.
``--no-find-links`` Blocks the addition of any link.
This parameter is useful if you want to avoid adding links defined in a
project easy_install is installing (whether it's a requested project or a
dependency). When used, ``--find-links`` is ignored.
Added in Distribute 0.6.11 and Setuptools 0.7.
``--index-url=URL, -i URL`` (New in 0.4a1; default changed in 0.6c7)
Specifies the base URL of the Python Package Index. The default is
https://pypi.org/simple/ if not specified. When a package is requested
that is not locally available or linked from a ``--find-links`` download
page, the package index will be searched for download pages for the needed
package, and those download pages will be searched for links to download
an egg or source distribution.
``--editable, -e`` (New in 0.6a1)
Only find and download source distributions for the specified projects,
unpacking them to subdirectories of the specified ``--build-directory``.
EasyInstall will not actually build or install the requested projects or
their dependencies; it will just find and extract them for you. See
`Editing and Viewing Source Packages`_ above for more details.
``--build-directory=DIR, -b DIR`` (UPDATED in 0.6a1)
Set the directory used to build source packages. If a package is built
from a source distribution or checkout, it will be extracted to a
subdirectory of the specified directory. The subdirectory will have the
same name as the extracted distribution's project, but in all-lowercase.
If a file or directory of that name already exists in the given directory,
a warning will be printed to the console, and the build will take place in
a temporary directory instead.
This option is most useful in combination with the ``--editable`` option,
which forces EasyInstall to *only* find and extract (but not build and
install) source distributions. See `Editing and Viewing Source Packages`_,
above, for more information.
``--verbose, -v, --quiet, -q`` (New in 0.4a4)
Control the level of detail of EasyInstall's progress messages. The
default detail level is "info", which prints information only about
relatively time-consuming operations like running a setup script, unpacking
an archive, or retrieving a URL. Using ``-q`` or ``--quiet`` drops the
detail level to "warn", which will only display installation reports,
warnings, and errors. Using ``-v`` or ``--verbose`` increases the detail
level to include individual file-level operations, link analysis messages,
and distutils messages from any setup scripts that get run. If you include
the ``-v`` option more than once, the second and subsequent uses are passed
down to any setup scripts, increasing the verbosity of their reporting as
well.
``--dry-run, -n`` (New in 0.4a4)
Don't actually install the package or scripts. This option is passed down
to any setup scripts run, so packages should not actually build either.
This does *not* skip downloading, nor does it skip extracting source
distributions to a temporary/build directory.
``--optimize=LEVEL``, ``-O LEVEL`` (New in 0.4a4)
If you are installing from a source distribution, and are *not* using the
``--zip-ok`` option, this option controls the optimization level for
compiling installed ``.py`` files to ``.pyo`` files. It does not affect
the compilation of modules contained in ``.egg`` files, only those in
``.egg`` directories. The optimization level can be set to 0, 1, or 2;
the default is 0 (unless it's set under ``install`` or ``install_lib`` in
one of your distutils configuration files).
``--record=FILENAME`` (New in 0.5a4)
Write a record of all installed files to FILENAME. This is basically the
same as the same option for the standard distutils "install" command, and
is included for compatibility with tools that expect to pass this option
to "setup.py install".
``--site-dirs=DIRLIST, -S DIRLIST`` (New in 0.6a1)
Specify one or more custom "site" directories (separated by commas).
"Site" directories are directories where ``.pth`` files are processed, such
as the main Python ``site-packages`` directory. As of 0.6a10, EasyInstall
automatically detects whether a given directory processes ``.pth`` files
(or can be made to do so), so you should not normally need to use this
option. It is is now only necessary if you want to override EasyInstall's
judgment and force an installation directory to be treated as if it
supported ``.pth`` files.
``--no-deps, -N`` (New in 0.6a6)
Don't install any dependencies. This is intended as a convenience for
tools that wrap eggs in a platform-specific packaging system. (We don't
recommend that you use it for anything else.)
``--allow-hosts=PATTERNS, -H PATTERNS`` (New in 0.6a6)
Restrict downloading and spidering to hosts matching the specified glob
patterns. E.g. ``-H *.python.org`` restricts web access so that only
packages listed and downloadable from machines in the ``python.org``
domain. The glob patterns must match the *entire* user/host/port section of
the target URL(s). For example, ``*.python.org`` will NOT accept a URL
like ``http://python.org/foo`` or ``http://www.python.org:8080/``.
Multiple patterns can be specified by separating them with commas. The
default pattern is ``*``, which matches anything.
In general, this option is mainly useful for blocking EasyInstall's web
access altogether (e.g. ``-Hlocalhost``), or to restrict it to an intranet
or other trusted site. EasyInstall will do the best it can to satisfy
dependencies given your host restrictions, but of course can fail if it
can't find suitable packages. EasyInstall displays all blocked URLs, so
that you can adjust your ``--allow-hosts`` setting if it is more strict
than you intended. Some sites may wish to define a restrictive default
setting for this option in their `configuration files`_, and then manually
override the setting on the command line as needed.
``--prefix=DIR`` (New in 0.6a10)
Use the specified directory as a base for computing the default
installation and script directories. On Windows, the resulting default
directories will be ``prefix\\Lib\\site-packages`` and ``prefix\\Scripts``,
while on other platforms the defaults will be
``prefix/lib/python2.X/site-packages`` (with the appropriate version
substituted) for libraries and ``prefix/bin`` for scripts.
Note that the ``--prefix`` option only sets the *default* installation and
script directories, and does not override the ones set on the command line
or in a configuration file.
``--local-snapshots-ok, -l`` (New in 0.6c6)
Normally, EasyInstall prefers to only install *released* versions of
projects, not in-development ones, because such projects may not
have a currently-valid version number. So, it usually only installs them
when their ``setup.py`` directory is explicitly passed on the command line.
However, if this option is used, then any in-development projects that were
installed using the ``setup.py develop`` command, will be used to build
eggs, effectively upgrading the "in-development" project to a snapshot
release. Normally, this option is used only in conjunction with the
``--always-copy`` option to create a distributable snapshot of every egg
needed to run an application.
Note that if you use this option, you must make sure that there is a valid
version number (such as an SVN revision number tag) for any in-development
projects that may be used, as otherwise EasyInstall may not be able to tell
what version of the project is "newer" when future installations or
upgrades are attempted.
.. _non-root installation:
Custom Installation Locations
-----------------------------
By default, EasyInstall installs python packages into Python's main ``site-packages`` directory,
and manages them using a custom ``.pth`` file in that same directory.
Very often though, a user or developer wants ``easy_install`` to install and manage python packages
in an alternative location, usually for one of 3 reasons:
1. They don't have access to write to the main Python site-packages directory.
2. They want a user-specific stash of packages, that is not visible to other users.
3. They want to isolate a set of packages to a specific python application, usually to minimize
the possibility of version conflicts.
Historically, there have been many approaches to achieve custom installation.
The following section lists only the easiest and most relevant approaches [1]_.
`Use the "--user" option`_
`Use the "--user" option and customize "PYTHONUSERBASE"`_
`Use "virtualenv"`_
.. [1] There are older ways to achieve custom installation using various ``easy_install`` and ``setup.py install`` options, combined with ``PYTHONPATH`` and/or ``PYTHONUSERBASE`` alterations, but all of these are effectively deprecated by the User scheme brought in by :pep:`370`.
Use the "--user" option
~~~~~~~~~~~~~~~~~~~~~~~
Python provides a User scheme for installation, which means that all
python distributions support an alternative install location that is specific to a user [3]_.
The Default location for each OS is explained in the python documentation
for the ``site.USER_BASE`` variable. This mode of installation can be turned on by
specifying the ``--user`` option to ``setup.py install`` or ``easy_install``.
This approach serves the need to have a user-specific stash of packages.
.. [3] Prior to the User scheme, there was the Home scheme, which is still available, but requires more effort than the User scheme to get packages recognized.
Use the "--user" option and customize "PYTHONUSERBASE"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The User scheme install location can be customized by setting the ``PYTHONUSERBASE`` environment
variable, which updates the value of ``site.USER_BASE``. To isolate packages to a specific
application, simply set the OS environment of that application to a specific value of
``PYTHONUSERBASE``, that contains just those packages.
Use "virtualenv"
~~~~~~~~~~~~~~~~
"virtualenv" is a 3rd-party python package that effectively "clones" a python installation, thereby
creating an isolated location to install packages. The evolution of "virtualenv" started before the existence
of the User installation scheme. "virtualenv" provides a version of ``easy_install`` that is
scoped to the cloned python install and is used in the normal way. "virtualenv" does offer various features
that the User installation scheme alone does not provide, e.g. the ability to hide the main python site-packages.
Please refer to the :pypi:`virtualenv` documentation for more details.
Package Index "API"
-------------------
Custom package indexes (and PyPI) must follow the following rules for
EasyInstall to be able to look up and download packages:
1. Except where stated otherwise, "pages" are HTML or XHTML, and "links"
refer to ``href`` attributes.
2. Individual project version pages' URLs must be of the form
``base/projectname/version``, where ``base`` is the package index's base URL.
3. Omitting the ``/version`` part of a project page's URL (but keeping the
trailing ``/``) should result in a page that is either:
a) The single active version of that project, as though the version had been
explicitly included, OR
b) A page with links to all of the active version pages for that project.
4. Individual project version pages should contain direct links to downloadable
distributions where possible. It is explicitly permitted for a project's
"long_description" to include URLs, and these should be formatted as HTML
links by the package index, as EasyInstall does no special processing to
identify what parts of a page are index-specific and which are part of the
project's supplied description.
5. Where available, MD5 information should be added to download URLs by
appending a fragment identifier of the form ``#md5=...``, where ``...`` is
the 32-character hex MD5 digest. EasyInstall will verify that the
downloaded file's MD5 digest matches the given value.
6. Individual project version pages should identify any "homepage" or
"download" URLs using ``rel="homepage"`` and ``rel="download"`` attributes
on the HTML elements linking to those URLs. Use of these attributes will
cause EasyInstall to always follow the provided links, unless it can be
determined by inspection that they are downloadable distributions. If the
links are not to downloadable distributions, they are retrieved, and if they
are HTML, they are scanned for download links. They are *not* scanned for
additional "homepage" or "download" links, as these are only processed for
pages that are part of a package index site.
7. The root URL of the index, if retrieved with a trailing ``/``, must result
in a page containing links to *all* projects' active version pages.
(Note: This requirement is a workaround for the absence of case-insensitive
``safe_name()`` matching of project names in URL paths. If project names are
matched in this fashion (e.g. via the PyPI server, mod_rewrite, or a similar
mechanism), then it is not necessary to include this all-packages listing
page.)
8. If a package index is accessed via a ``file://`` URL, then EasyInstall will
automatically use ``index.html`` files, if present, when trying to read a
directory with a trailing ``/`` on the URL.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/functionalities.rst 0000644 0001751 0000173 00000002653 14467657412 022442 0 ustar 00runner docker "Eggsecutable" Scripts
----------------------
.. deprecated:: 45.3.0
Occasionally, there are situations where it's desirable to make an ``.egg``
file directly executable. You can do this by including an entry point such
as the following::
setup(
# other arguments here...
entry_points={
"setuptools.installation": [
"eggsecutable = my_package.some_module:main_func",
]
}
)
Any eggs built from the above setup script will include a short executable
prelude that imports and calls ``main_func()`` from ``my_package.some_module``.
The prelude can be run on Unix-like platforms (including Mac and Linux) by
invoking the egg with ``/bin/sh``, or by enabling execute permissions on the
``.egg`` file. For the executable prelude to run, the appropriate version of
Python must be available via the ``PATH`` environment variable, under its
"long" name. That is, if the egg is built for Python 2.3, there must be a
``python2.3`` executable present in a directory on ``PATH``.
IMPORTANT NOTE: Eggs with an "eggsecutable" header cannot be renamed, or
invoked via symlinks. They *must* be invoked using their original filename, in
order to ensure that, once running, ``pkg_resources`` will know what project
and version is in use. The header script will check this and exit with an
error if the ``.egg`` file has been renamed or is invoked via a symlink that
changes its base name.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/index.rst 0000644 0001751 0000173 00000001537 14467657412 020351 0 ustar 00runner docker ======================================================
Guides on backward compatibility & deprecated practice
======================================================
``Setuptools`` has undergone tremendous changes since its first debut. As its
development continues to roll forward, many of the practice and mechanisms it
had established are now considered deprecated. But they still remain relevant
as a plethora of libraries continue to depend on them. Many people also find
it necessary to equip themselves with the knowledge to better support backward
compatibility. This guide aims to provide the essential information for such
objectives.
.. toctree::
:maxdepth: 1
changed_keywords
dependency_links
python_eggs
easy_install
zip_safe
resource_extraction
distutils/index
distutils-legacy
functionalities
commands
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/python_eggs.rst 0000644 0001751 0000173 00000074337 14467657412 021600 0 ustar 00runner docker =====================================
The Internal Structure of Python Eggs
=====================================
STOP! This is not the first document you should read!
----------------------
Eggs and their Formats
----------------------
A "Python egg" is a logical structure embodying the release of a
specific version of a Python project, comprising its code, resources,
and metadata. There are multiple formats that can be used to physically
encode a Python egg, and others can be developed. However, a key
principle of Python eggs is that they should be discoverable and
importable. That is, it should be possible for a Python application to
easily and efficiently find out what eggs are present on a system, and
to ensure that the desired eggs' contents are importable.
There are two basic formats currently implemented for Python eggs:
1. ``.egg`` format: a directory or zipfile *containing* the project's
code and resources, along with an ``EGG-INFO`` subdirectory that
contains the project's metadata
2. ``.egg-info`` format: a file or directory placed *adjacent* to the
project's code and resources, that directly contains the project's
metadata.
Both formats can include arbitrary Python code and resources, including
static data files, package and non-package directories, Python
modules, C extension modules, and so on. But each format is optimized
for different purposes.
The ``.egg`` format is well-suited to distribution and the easy
uninstallation or upgrades of code, since the project is essentially
self-contained within a single directory or file, unmingled with any
other projects' code or resources. It also makes it possible to have
multiple versions of a project simultaneously installed, such that
individual programs can select the versions they wish to use.
The ``.egg-info`` format, on the other hand, was created to support
backward-compatibility, performance, and ease of installation for system
packaging tools that expect to install all projects' code and resources
to a single directory (e.g. ``site-packages``). Placing the metadata
in that same directory simplifies the installation process, since it
isn't necessary to create ``.pth`` files or otherwise modify
``sys.path`` to include each installed egg.
Its disadvantage, however, is that it provides no support for clean
uninstallation or upgrades, and of course only a single version of a
project can be installed to a given directory. Thus, support from a
package management tool is required. (This is why setuptools' "install"
command refers to this type of egg installation as "single-version,
externally managed".) Also, they lack sufficient data to allow them to
be copied from their installation source. easy_install can "ship" an
application by copying ``.egg`` files or directories to a target
location, but it cannot do this for ``.egg-info`` installs, because
there is no way to tell what code and resources belong to a particular
egg -- there may be several eggs "scrambled" together in a single
installation location, and the ``.egg-info`` format does not currently
include a way to list the files that were installed. (This may change
in a future version.)
Code and Resources
==================
The layout of the code and resources is dictated by Python's normal
import layout, relative to the egg's "base location".
For the ``.egg`` format, the base location is the ``.egg`` itself. That
is, adding the ``.egg`` filename or directory name to ``sys.path``
makes its contents importable.
For the ``.egg-info`` format, however, the base location is the
directory that *contains* the ``.egg-info``, and thus it is the
directory that must be added to ``sys.path`` to make the egg importable.
(Note that this means that the "normal" installation of a package to a
``sys.path`` directory is sufficient to make it an "egg" if it has an
``.egg-info`` file or directory installed alongside of it.)
Project Metadata
=================
If eggs contained only code and resources, there would of course be
no difference between them and any other directory or zip file on
``sys.path``. Thus, metadata must also be included, using a metadata
file or directory.
For the ``.egg`` format, the metadata is placed in an ``EGG-INFO``
subdirectory, directly within the ``.egg`` file or directory. For the
``.egg-info`` format, metadata is stored directly within the
``.egg-info`` directory itself.
The minimum project metadata that all eggs must have is a standard
Python ``PKG-INFO`` file, named ``PKG-INFO`` and placed within the
metadata directory appropriate to the format. Because it's possible for
this to be the only metadata file included, ``.egg-info`` format eggs
are not required to be a directory; they can just be a ``.egg-info``
file that directly contains the ``PKG-INFO`` metadata. This eliminates
the need to create a directory just to store one file. This option is
*not* available for ``.egg`` formats, since setuptools always includes
other metadata. (In fact, setuptools itself never generates
``.egg-info`` files, either; the support for using files was added so
that the requirement could easily be satisfied by other tools, such
as distutils).
In addition to the ``PKG-INFO`` file, an egg's metadata directory may
also include files and directories representing various forms of
optional standard metadata (see the section on `Standard Metadata`_,
below) or user-defined metadata required by the project. For example,
some projects may define a metadata format to describe their application
plugins, and metadata in this format would then be included by plugin
creators in their projects' metadata directories.
Filename-Embedded Metadata
==========================
To allow introspection of installed projects and runtime resolution of
inter-project dependencies, a certain amount of information is embedded
in egg filenames. At a minimum, this includes the project name, and
ideally will also include the project version number. Optionally, it
can also include the target Python version and required runtime
platform if platform-specific C code is included. The syntax of an
egg filename is as follows::
name ["-" version ["-py" pyver ["-" required_platform]]] "." ext
The "name" and "version" should be escaped using the ``to_filename()``
function provided by ``pkg_resources``, after first processing them with
``safe_name()`` and ``safe_version()`` respectively. These latter two
functions can also be used to later "unescape" these parts of the
filename. (For a detailed description of these transformations, please
see the "Parsing Utilities" section of the ``pkg_resources`` manual.)
The "pyver" string is the Python major version, as found in the first
3 characters of ``sys.version``. "required_platform" is essentially
a distutils ``get_platform()`` string, but with enhancements to properly
distinguish Mac OS versions. (See the ``get_build_platform()``
documentation in the "Platform Utilities" section of the
``pkg_resources`` manual for more details.)
Finally, the "ext" is either ``.egg`` or ``.egg-info``, as appropriate
for the egg's format.
Normally, an egg's filename should include at least the project name and
version, as this allows the runtime system to find desired project
versions without having to read the egg's PKG-INFO to determine its
version number.
Setuptools, however, only includes the version number in the filename
when an ``.egg`` file is built using the ``bdist_egg`` command, or when
an ``.egg-info`` directory is being installed by the
``install_egg_info`` command. When generating metadata for use with the
original source tree, it only includes the project name, so that the
directory will not have to be renamed each time the project's version
changes.
This is especially important when version numbers change frequently, and
the source metadata directory is kept under version control with the
rest of the project. (As would be the case when the project's source
includes project-defined metadata that is not generated from by
setuptools from data in the setup script.)
Egg Links
=========
In addition to the ``.egg`` and ``.egg-info`` formats, there is a third
egg-related extension that you may encounter on occasion: ``.egg-link``
files.
These files are not eggs, strictly speaking. They simply provide a way
to reference an egg that is not physically installed in the desired
location. They exist primarily as a cross-platform alternative to
symbolic links, to support "installing" code that is being developed in
a different location than the desired installation location. For
example, if a user is developing an application plugin in their home
directory, but the plugin needs to be "installed" in an application
plugin directory, running "setup.py develop -md /path/to/app/plugins"
will install an ``.egg-link`` file in ``/path/to/app/plugins``, that
tells the egg runtime system where to find the actual egg (the user's
project source directory and its ``.egg-info`` subdirectory).
``.egg-link`` files are named following the format for ``.egg`` and
``.egg-info`` names, but only the project name is included; no version,
Python version, or platform information is included. When the runtime
searches for available eggs, ``.egg-link`` files are opened and the
actual egg file/directory name is read from them.
Each ``.egg-link`` file should contain a single file or directory name,
with no newlines. This filename should be the base location of one or
more eggs. That is, the name must either end in ``.egg``, or else it
should be the parent directory of one or more ``.egg-info`` format eggs.
As of setuptools 0.6c6, the path may be specified as a platform-independent
(i.e. ``/``-separated) relative path from the directory containing the
``.egg-link`` file, and a second line may appear in the file, specifying a
platform-independent relative path from the egg's base directory to its
setup script directory. This allows installation tools such as EasyInstall
to find the project's setup directory and build eggs or perform other setup
commands on it.
-----------------
Standard Metadata
-----------------
In addition to the minimum required ``PKG-INFO`` metadata, projects can
include a variety of standard metadata files or directories, as
described below. Except as otherwise noted, these files and directories
are automatically generated by setuptools, based on information supplied
in the setup script or through analysis of the project's code and
resources.
Most of these files and directories are generated via "egg-info
writers" during execution of the setuptools ``egg_info`` command, and
are listed in the ``egg_info.writers`` entry point group defined by
setuptools' own ``setup.py`` file.
Project authors can register their own metadata writers as entry points
in this group (as described in the setuptools manual under "Adding new
EGG-INFO Files") to cause setuptools to generate project-specific
metadata files or directories during execution of the ``egg_info``
command. It is up to project authors to document these new metadata
formats, if they create any.
``.txt`` File Formats
=====================
Files described in this section that have ``.txt`` extensions have a
simple lexical format consisting of a sequence of text lines, each line
terminated by a linefeed character (regardless of platform). Leading
and trailing whitespace on each line is ignored, as are blank lines and
lines whose first nonblank character is a ``#`` (comment symbol). (This
is the parsing format defined by the ``yield_lines()`` function of
the ``pkg_resources`` module.)
All ``.txt`` files defined by this section follow this format, but some
are also "sectioned" files, meaning that their contents are divided into
sections, using square-bracketed section headers akin to Windows
``.ini`` format. Note that this does *not* imply that the lines within
the sections follow an ``.ini`` format, however. Please see an
individual metadata file's documentation for a description of what the
lines and section names mean in that particular file.
Sectioned files can be parsed using the ``split_sections()`` function;
see the "Parsing Utilities" section of the ``pkg_resources`` manual for
for details.
Dependency Metadata
===================
``requires.txt``
----------------
This is a "sectioned" text file. Each section is a sequence of
"requirements", as parsed by the ``parse_requirements()`` function;
please see the ``pkg_resources`` manual for the complete requirement
parsing syntax.
The first, unnamed section (i.e., before the first section header) in
this file is the project's core requirements, which must be installed
for the project to function. (Specified using the ``install_requires``
keyword to ``setup()``).
The remaining (named) sections describe the project's "extra"
requirements, as specified using the ``extras_require`` keyword to
``setup()``. The section name is the name of the optional feature, and
the section body lists that feature's dependencies.
Note that it is not normally necessary to inspect this file directly;
``pkg_resources.Distribution`` objects have a ``requires()`` method
that can be used to obtain ``Requirement`` objects describing the
project's core and optional dependencies.
``setup_requires.txt``
----------------------
Much like ``requires.txt`` except represents the requirements
specified by the ``setup_requires`` parameter to the Distribution.
``dependency_links.txt``
------------------------
A list of dependency URLs, one per line, as specified using the
``dependency_links`` keyword to ``setup()``. These may be direct
download URLs, or the URLs of web pages containing direct download
links. Please see the setuptools manual for more information on
specifying this option.
``depends.txt`` -- Obsolete, do not create!
-------------------------------------------
This file follows an identical format to ``requires.txt``, but is
obsolete and should not be used. The earliest versions of setuptools
required users to manually create and maintain this file, so the runtime
still supports reading it, if it exists. The new filename was created
so that it could be automatically generated from ``setup()`` information
without overwriting an existing hand-created ``depends.txt``, if one
was already present in the project's source ``.egg-info`` directory.
``namespace_packages.txt`` -- Namespace Package Metadata
========================================================
A list of namespace package names, one per line, as supplied to the
``namespace_packages`` keyword to ``setup()``. Please see the manuals
for setuptools and ``pkg_resources`` for more information about
namespace packages.
``entry_points.txt`` -- "Entry Point"/Plugin Metadata
=====================================================
This is a "sectioned" text file, whose contents encode the
``entry_points`` keyword supplied to ``setup()``. All sections are
named, as the section names specify the entry point groups in which the
corresponding section's entry points are registered.
Each section is a sequence of "entry point" lines, each parseable using
the ``EntryPoint.parse`` classmethod; please see the ``pkg_resources``
manual for the complete entry point parsing syntax.
Note that it is not necessary to parse this file directly; the
``pkg_resources`` module provides a variety of APIs to locate and load
entry points automatically. Please see the setuptools and
``pkg_resources`` manuals for details on the nature and uses of entry
points.
The ``scripts`` Subdirectory
============================
This directory is currently only created for ``.egg`` files built by
the setuptools ``bdist_egg`` command. It will contain copies of all
of the project's "traditional" scripts (i.e., those specified using the
``scripts`` keyword to ``setup()``). This is so that they can be
reconstituted when an ``.egg`` file is installed.
The scripts are placed here using the distutils' standard
``install_scripts`` command, so any ``#!`` lines reflect the Python
installation where the egg was built. But instead of copying the
scripts to the local script installation directory, EasyInstall writes
short wrapper scripts that invoke the original scripts from inside the
egg, after ensuring that sys.path includes the egg and any eggs it
depends on. For more about `script wrappers`_, see the section below on
`Installation and Path Management Issues`_.
Zip Support Metadata
====================
``native_libs.txt``
-------------------
A list of C extensions and other dynamic link libraries contained in
the egg, one per line. Paths are ``/``-separated and relative to the
egg's base location.
This file is generated as part of ``bdist_egg`` processing, and as such
only appears in ``.egg`` files (and ``.egg`` directories created by
unpacking them). It is used to ensure that all libraries are extracted
from a zipped egg at the same time, in case there is any direct linkage
between them. Please see the `Zip File Issues`_ section below for more
information on library and resource extraction from ``.egg`` files.
``eager_resources.txt``
-----------------------
A list of resource files and/or directories, one per line, as specified
via the ``eager_resources`` keyword to ``setup()``. Paths are
``/``-separated and relative to the egg's base location.
Resource files or directories listed here will be extracted
simultaneously, if any of the named resources are extracted, or if any
native libraries listed in ``native_libs.txt`` are extracted. Please
see the setuptools manual for details on what this feature is used for
and how it works, as well as the `Zip File Issues`_ section below.
``zip-safe`` and ``not-zip-safe``
---------------------------------
These are zero-length files, and either one or the other should exist.
If ``zip-safe`` exists, it means that the project will work properly
when installed as an ``.egg`` zipfile, and conversely the existence of
``not-zip-safe`` means the project should not be installed as an
``.egg`` file. The ``zip_safe`` option to setuptools' ``setup()``
determines which file will be written. If the option isn't provided,
setuptools attempts to make its own assessment of whether the package
can work, based on code and content analysis.
If neither file is present at installation time, EasyInstall defaults
to assuming that the project should be unzipped. (Command-line options
to EasyInstall, however, take precedence even over an existing
``zip-safe`` or ``not-zip-safe`` file.)
Note that these flag files appear only in ``.egg`` files generated by
``bdist_egg``, and in ``.egg`` directories created by unpacking such an
``.egg`` file.
``top_level.txt`` -- Conflict Management Metadata
=================================================
This file is a list of the top-level module or package names provided
by the project, one Python identifier per line.
Subpackages are not included; a project containing both a ``foo.bar``
and a ``foo.baz`` would include only one line, ``foo``, in its
``top_level.txt``.
This data is used by ``pkg_resources`` at runtime to issue a warning if
an egg is added to ``sys.path`` when its contained packages may have
already been imported.
(It was also once used to detect conflicts with non-egg packages at
installation time, but in more recent versions, setuptools installs eggs
in such a way that they always override non-egg packages, thus
preventing a problem from arising.)
``SOURCES.txt`` -- Source Files Manifest
========================================
This file is roughly equivalent to the distutils' ``MANIFEST`` file.
The differences are as follows:
* The filenames always use ``/`` as a path separator, which must be
converted back to a platform-specific path whenever they are read.
* The file is automatically generated by setuptools whenever the
``egg_info`` or ``sdist`` commands are run, and it is *not*
user-editable.
Although this metadata is included with distributed eggs, it is not
actually used at runtime for any purpose. Its function is to ensure
that setuptools-built *source* distributions can correctly discover
what files are part of the project's source, even if the list had been
generated using revision control metadata on the original author's
system.
In other words, ``SOURCES.txt`` has little or no runtime value for being
included in distributed eggs, and it is possible that future versions of
the ``bdist_egg`` and ``install_egg_info`` commands will strip it before
installation or distribution. Therefore, do not rely on its being
available outside of an original source directory or source
distribution.
------------------------------
Other Technical Considerations
------------------------------
Zip File Issues
===============
Although zip files resemble directories, they are not fully
substitutable for them. Most platforms do not support loading dynamic
link libraries contained in zipfiles, so it is not possible to directly
import C extensions from ``.egg`` zipfiles. Similarly, there are many
existing libraries -- whether in Python or C -- that require actual
operating system filenames, and do not work with arbitrary "file-like"
objects or in-memory strings, and thus cannot operate directly on the
contents of zip files.
To address these issues, the ``pkg_resources`` module provides a
"resource API" to support obtaining either the contents of a resource,
or a true operating system filename for the resource. If the egg
containing the resource is a directory, the resource's real filename
is simply returned. However, if the egg is a zipfile, then the
resource is first extracted to a cache directory, and the filename
within the cache is returned.
The cache directory is determined by the ``pkg_resources`` API; please
see the ``set_cache_path()`` and ``get_default_cache()`` documentation
for details.
The Extraction Process
----------------------
Resources are extracted to a cache subdirectory whose name is based
on the enclosing ``.egg`` filename and the path to the resource. If
there is already a file of the correct name, size, and timestamp, its
filename is returned to the requester. Otherwise, the desired file is
extracted first to a temporary name generated using
``mkstemp(".$extract",target_dir)``, and then its timestamp is set to
match the one in the zip file, before renaming it to its final name.
(Some collision detection and resolution code is used to handle the
fact that Windows doesn't overwrite files when renaming.)
If a resource directory is requested, all of its contents are
recursively extracted in this fashion, to ensure that the directory
name can be used as if it were valid all along.
If the resource requested for extraction is listed in the
``native_libs.txt`` or ``eager_resources.txt`` metadata files, then
*all* resources listed in *either* file will be extracted before the
requested resource's filename is returned, thus ensuring that all
C extensions and data used by them will be simultaneously available.
Extension Import Wrappers
-------------------------
Since Python's built-in zip import feature does not support loading
C extension modules from zipfiles, the setuptools ``bdist_egg`` command
generates special import wrappers to make it work.
The wrappers are ``.py`` files (along with corresponding ``.pyc``
and/or ``.pyo`` files) that have the same module name as the
corresponding C extension. These wrappers are located in the same
package directory (or top-level directory) within the zipfile, so that
say, ``foomodule.so`` will get a corresponding ``foo.py``, while
``bar/baz.pyd`` will get a corresponding ``bar/baz.py``.
These wrapper files contain a short stanza of Python code that asks
``pkg_resources`` for the filename of the corresponding C extension,
then reloads the module using the obtained filename. This will cause
``pkg_resources`` to first ensure that all of the egg's C extensions
(and any accompanying "eager resources") are extracted to the cache
before attempting to link to the C library.
Note, by the way, that ``.egg`` directories will also contain these
wrapper files. However, Python's default import priority is such that
C extensions take precedence over same-named Python modules, so the
import wrappers are ignored unless the egg is a zipfile.
Installation and Path Management Issues
=======================================
Python's initial setup of ``sys.path`` is very dependent on the Python
version and installation platform, as well as how Python was started
(i.e., script vs. ``-c`` vs. ``-m`` vs. interactive interpreter).
In fact, Python also provides only two relatively robust ways to affect
``sys.path`` outside of direct manipulation in code: the ``PYTHONPATH``
environment variable, and ``.pth`` files.
However, with no cross-platform way to safely and persistently change
environment variables, this leaves ``.pth`` files as EasyInstall's only
real option for persistent configuration of ``sys.path``.
But ``.pth`` files are rather strictly limited in what they are allowed
to do normally. They add directories only to the *end* of ``sys.path``,
after any locally-installed ``site-packages`` directory, and they are
only processed *in* the ``site-packages`` directory to start with.
This is a double whammy for users who lack write access to that
directory, because they can't create a ``.pth`` file that Python will
read, and even if a sympathetic system administrator adds one for them
that calls ``site.addsitedir()`` to allow some other directory to
contain ``.pth`` files, they won't be able to install newer versions of
anything that's installed in the systemwide ``site-packages``, because
their paths will still be added *after* ``site-packages``.
So EasyInstall applies two workarounds to solve these problems.
The first is that EasyInstall leverages ``.pth`` files' "import" feature
to manipulate ``sys.path`` and ensure that anything EasyInstall adds
to a ``.pth`` file will always appear before both the standard library
and the local ``site-packages`` directories. Thus, it is always
possible for a user who can write a Python-read ``.pth`` file to ensure
that their packages come first in their own environment.
Second, when installing to a ``PYTHONPATH`` directory (as opposed to
a "site" directory like ``site-packages``) EasyInstall will also install
a special version of the ``site`` module. Because it's in a
``PYTHONPATH`` directory, this module will get control before the
standard library version of ``site`` does. It will record the state of
``sys.path`` before invoking the "real" ``site`` module, and then
afterwards it processes any ``.pth`` files found in ``PYTHONPATH``
directories, including all the fixups needed to ensure that eggs always
appear before the standard library in sys.path, but are in a relative
order to one another that is defined by their ``PYTHONPATH`` and
``.pth``-prescribed sequence.
The net result of these changes is that ``sys.path`` order will be
as follows at runtime:
1. The ``sys.argv[0]`` directory, or an empty string if no script
is being executed.
2. All eggs installed by EasyInstall in any ``.pth`` file in each
``PYTHONPATH`` directory, in order first by ``PYTHONPATH`` order,
then normal ``.pth`` processing order (which is to say alphabetical
by ``.pth`` filename, then by the order of listing within each
``.pth`` file).
3. All eggs installed by EasyInstall in any ``.pth`` file in each "site"
directory (such as ``site-packages``), following the same ordering
rules as for the ones on ``PYTHONPATH``.
4. The ``PYTHONPATH`` directories themselves, in their original order
5. Any paths from ``.pth`` files found on ``PYTHONPATH`` that were *not*
eggs installed by EasyInstall, again following the same relative
ordering rules.
6. The standard library and "site" directories, along with the contents
of any ``.pth`` files found in the "site" directories.
Notice that sections 1, 4, and 6 comprise the "normal" Python setup for
``sys.path``. Sections 2 and 3 are inserted to support eggs, and
section 5 emulates what the "normal" semantics of ``.pth`` files on
``PYTHONPATH`` would be if Python natively supported them.
For further discussion of the tradeoffs that went into this design, as
well as notes on the actual magic inserted into ``.pth`` files to make
them do these things, please see also the following messages to the
distutils-SIG mailing list:
* http://mail.python.org/pipermail/distutils-sig/2006-February/006026.html
* http://mail.python.org/pipermail/distutils-sig/2006-March/006123.html
Script Wrappers
---------------
EasyInstall never directly installs a project's original scripts to
a script installation directory. Instead, it writes short wrapper
scripts that first ensure that the project's dependencies are active
on sys.path, before invoking the original script. These wrappers
have a #! line that points to the version of Python that was used to
install them, and their second line is always a comment that indicates
the type of script wrapper, the project version required for the script
to run, and information identifying the script to be invoked.
The format of this marker line is::
"# EASY-INSTALL-" script_type ": " tuple_of_strings "\n"
The ``script_type`` is one of ``SCRIPT``, ``DEV-SCRIPT``, or
``ENTRY-SCRIPT``. The ``tuple_of_strings`` is a comma-separated
sequence of Python string constants. For ``SCRIPT`` and ``DEV-SCRIPT``
wrappers, there are two strings: the project version requirement, and
the script name (as a filename within the ``scripts`` metadata
directory). For ``ENTRY-SCRIPT`` wrappers, there are three:
the project version requirement, the entry point group name, and the
entry point name. (See the "Automatic Script Creation" section in the
setuptools manual for more information about entry point scripts.)
In each case, the project version requirement string will be a string
parseable with the ``pkg_resources`` modules' ``Requirement.parse()``
classmethod. The only difference between a ``SCRIPT`` wrapper and a
``DEV-SCRIPT`` is that a ``DEV-SCRIPT`` actually executes the original
source script in the project's source tree, and is created when the
"setup.py develop" command is run. A ``SCRIPT`` wrapper, on the other
hand, uses the "installed" script written to the ``EGG-INFO/scripts``
subdirectory of the corresponding ``.egg`` zipfile or directory.
(``.egg-info`` eggs do not have script wrappers associated with them,
except in the "setup.py develop" case.)
The purpose of including the marker line in generated script wrappers is
to facilitate introspection of installed scripts, and their relationship
to installed eggs. For example, an uninstallation tool could use this
data to identify what scripts can safely be removed, and/or identify
what scripts would stop working if a particular egg is uninstalled.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/resource_extraction.rst 0000644 0001751 0000173 00000005747 14467657412 023340 0 ustar 00runner docker .. _Automatic Resource Extraction:
Automatic Resource Extraction
=============================
In a modern setup, Python packages are usually installed as directories,
and all the files can be found on deterministic locations on the disk.
This means that most of the tools expect package resources to be "real" files.
There are a few occasions however that packages are loaded in a different way
(e.g., from a zip file), which is incompatible with the assumptions mentioned above.
Moreover, a package developer may also include non-extension native libraries or other files that
C extensions may expect to be able to access.
In these scenarios, the use of :mod:`importlib.resources` is recommended.
Old implementations (prior to the advent of :mod:`importlib.resources`) and
long-living projects, however, may still rely on the library ``pkg_resources``
to access these files.
If you have to support such systems, or want to provide backward compatibility
for ``pkg_resources``, you may need to add an special configuration
to ``setuptools`` when packaging a project.
This can be done by listing as ``eager_resources`` (argument to ``setup()``
in ``setup.py`` or field in ``setup.cfg``) all the files that need to be
extracted together, whenever a C extension in the project is imported.
This is especially important if your project includes shared libraries *other*
than ``distutils``/``setuptools``-built C extensions, and those shared libraries use file
extensions other than ``.dll``, ``.so``, or ``.dylib``, which are the
extensions that setuptools 0.6a8 and higher automatically detects as shared
libraries and adds to the ``native_libs.txt`` file for you. Any shared
libraries whose names do not end with one of those extensions should be listed
as ``eager_resources``, because they need to be present in the filesystem when
he C extensions that link to them are used.
The ``pkg_resources`` runtime for compressed packages will automatically
extract *all* C extensions and ``eager_resources`` at the same time, whenever
*any* C extension or eager resource is requested via the ``resource_filename()``
API. (C extensions are imported using ``resource_filename()`` internally.)
This ensures that C extensions will see all of the "real" files that they
expect to see.
Note also that you can list directory resource names in ``eager_resources`` as
well, in which case the directory's contents (including subdirectories) will be
extracted whenever any C extension or eager resource is requested.
Please note that if you're not sure whether you need to use this argument, you
don't! It's really intended to support projects with lots of non-Python
dependencies and as a last resort for crufty projects that can't otherwise
handle being compressed. If your package is pure Python, Python plus data
files, or Python plus C, you really don't need this. You've got to be using
either C or an external program that needs "real" files in your project before
there's any possibility of ``eager_resources`` being relevant to your project.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/deprecated/zip_safe.rst 0000644 0001751 0000173 00000007101 14467657412 021033 0 ustar 00runner docker Understanding the ``zip_safe`` flag
===================================
The ``zip_safe`` flag is a ``setuptools`` configuration mainly associated
with the ``egg`` distribution format
(which got replaced in the ecosystem by the newer ``wheel`` format) and the
``easy_install`` command (deprecated in ``setuptools`` v58.3.0).
It is very unlikely that the values of ``zip_safe`` will affect modern
deployments that use :pypi:`pip` for installing packages.
Moreover, new users of ``setuptools`` should not attempt to create egg files
using the deprecated ``build_egg`` command.
Therefore, this flag is considered **obsolete**.
This document, however, describes what was the historical motivation behind
this flag, and how it was used.
Historical Motivation
---------------------
For some use cases (such as bundling as part of a larger application), Python
packages may be run directly from a zip file.
Not all packages, however, are capable of running in compressed form, because
they may expect to be able to access either source code or data files as
normal operating system files.
In the past, ``setuptools`` would install a project distributed
as a zipfile or a directory (via the ``easy_install`` command or
``python setup.py install``),
the default choice being determined by the project's ``zip_safe`` flag.
How the ``zip_safe`` flag was used?
-----------------------------------
To set this flag, a developer would pass a boolean value for the ``zip_safe`` argument to the
``setup()`` function, or omit it. When omitted, the ``bdist_egg``
command would analyze the project's contents to see if it could detect any
conditions preventing the project from working in a zipfile.
This was extremely conservative: ``bdist_egg`` would consider the
project unsafe if it contained any C extensions or datafiles whatsoever. This
does *not* mean that the project couldn't or wouldn't work as a zipfile! It just
means that the ``bdist_egg`` authors were not yet comfortable asserting that
the project *would* work. If the project did not contain any C or data files, and did not
attempt to perform ``__file__`` or ``__path__`` introspection or source code manipulation, then
there was an extremely solid chance the project will work when installed as a
zipfile. (And if the project used ``pkg_resources`` for all its data file
access, then C extensions and other data files shouldn't be a problem at all.
See the :ref:`Accessing Data Files at Runtime` section for more information.)
The developer could manually set ``zip_safe`` to ``True`` to perform tests,
or to override the default behaviour (after checking all the warnings and
understanding the implications), this would allow ``setuptools`` to install the
project as a zip file. Alternatively, by setting ``zip_safe`` to ``False``,
developers could force ``setuptools`` to always install the project as a
directory.
Modern ways of loading packages from zip files
----------------------------------------------
Currently, popular Python package installers (such as :pypi:`pip`) and package
indexes (such as PyPI_) consider that distribution packages are always
installed as a directory.
It is however still possible to load packages from zip files added to
:obj:`sys.path`, thanks to the :mod:`zipimport` module
and the :mod:`importlib` machinery provided by Python standard library.
When working with modules loaded from a zip file, it is important to keep in
mind that values of ``__file__`` and ``__path__`` might not work as expected.
Please check the documentation for :mod:`importlib.resources`, if file
locations are important for your use case.
.. _PyPI: https://pypi.org
././@PaxHeader 0000000 0000000 0000000 00000000034 00000000000 010212 x ustar 00 28 mtime=1692360483.4875476
setuptools-68.1.2/docs/development/ 0000755 0001751 0000173 00000000000 14467657443 016730 5 ustar 00runner docker ././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/development/developer-guide.rst 0000644 0001751 0000173 00000010747 14467657412 022547 0 ustar 00runner docker ================================
Developer's Guide for Setuptools
================================
If you want to know more about contributing on Setuptools, this is the place.
-------------------
Recommended Reading
-------------------
Please read `How to write the perfect pull request
`_ for some tips
on contributing to open source projects. Although the article is not
authoritative, it was authored by the maintainer of Setuptools, so reflects
his opinions and will improve the likelihood of acceptance and quality of
contribution.
------------------
Project Management
------------------
Setuptools is maintained primarily in GitHub at `this home
`_. Setuptools is maintained under the
Python Packaging Authority (PyPA) with several core contributors. All bugs
for Setuptools are filed and the canonical source is maintained in GitHub.
User support and discussions are done through
`GitHub Discussions `_,
or the issue tracker (for specific issues).
Discussions about development happen on GitHub Discussions or
the ``setuptools`` channel on `PyPA Discord `_.
-----------------
Authoring Tickets
-----------------
Before authoring any source code, it's often prudent to file a ticket
describing the motivation behind making changes. First search to see if a
ticket already exists for your issue. If not, create one. Try to think from
the perspective of the reader. Explain what behavior you expected, what you
got instead, and what factors might have contributed to the unexpected
behavior. In GitHub, surround a block of code or traceback with the triple
backtick "\`\`\`" so that it is formatted nicely.
Filing a ticket provides a forum for justification, discussion, and
clarification. The ticket provides a record of the purpose for the change and
any hard decisions that were made. It provides a single place for others to
reference when trying to understand why the software operates the way it does
or why certain changes were made.
Setuptools makes extensive use of hyperlinks to tickets in the changelog so
that system integrators and other users can get a quick summary, but then
jump to the in-depth discussion about any subject referenced.
---------------------
Making a pull request
---------------------
When making a pull request, please
:ref:`include a short summary of the changes ` and a reference to any issue tickets that the PR is
intended to solve.
All PRs with code changes should include tests. All changes should
include a changelog entry.
.. include:: ../../newsfragments/README.rst
-------------------
Auto-Merge Requests
-------------------
To support running all code through CI, even lightweight contributions,
the project employs Mergify to auto-merge pull requests tagged as
auto-merge.
Use ``hub pull-request -l auto-merge`` to create such a pull request
from the command line after pushing a new branch.
-------
Testing
-------
The primary tests are run using tox. Make sure you have tox installed,
and invoke it::
$ tox
Under continuous integration, additional tests may be run. See the
``.travis.yml`` file for full details on the tests run under Travis-CI.
-------------------
Semantic Versioning
-------------------
Setuptools follows ``semver``.
.. explain value of reflecting meaning in versions.
----------------------
Building Documentation
----------------------
Setuptools relies on the `Sphinx`_ system for building documentation.
The `published documentation`_ is hosted on Read the Docs.
To build the docs locally, use tox::
$ tox -e docs
.. _Sphinx: http://www.sphinx-doc.org/en/master/
.. _published documentation: https://setuptools.pypa.io/en/latest/
---------------------
Vendored Dependencies
---------------------
Setuptools has some dependencies, but due to `bootstrapping issues
`_, those dependencies
cannot be declared as they won't be resolved soon enough to build
setuptools from source. Eventually, this limitation may be lifted as
PEP 517/518 reach ubiquitous adoption, but for now, Setuptools
cannot declare dependencies other than through
``setuptools/_vendor/vendored.txt`` and
``pkg_resources/_vendor/vendored.txt``.
All the dependencies specified in these files are "vendorized" using a
simple Python script ``tools/vendor.py``.
To refresh the dependencies, run the following command::
$ tox -e vendor
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/development/index.rst 0000644 0001751 0000173 00000002657 14467657412 020577 0 ustar 00runner docker -------------------------
Development on Setuptools
-------------------------
Setuptools is maintained by the Python community under the Python Packaging
Authority (PyPA) and led by Jason R. Coombs.
This document describes the process by which Setuptools is developed.
This document assumes the reader has some passing familiarity with
*using* setuptools, the ``pkg_resources`` module, and pip. It
does not attempt to explain basic concepts like inter-project
dependencies, nor does it contain detailed lexical syntax for most
file formats. Neither does it explain concepts like "namespace
packages" or "resources" in any detail, as all of these subjects are
covered at length in the setuptools developer's guide and the
``pkg_resources`` reference manual.
Instead, this is **internal** documentation for how those concepts and
features are *implemented* in concrete terms. It is intended for people
who are working on the setuptools code base, who want to be able to
troubleshoot setuptools problems, want to write code that reads the file
formats involved, or want to otherwise tinker with setuptools-generated
files and directories.
Note, however, that these are all internal implementation details and
are therefore subject to change; stick to the published API if you don't
want to be responsible for keeping your code from breaking when
setuptools changes. You have been warned.
.. toctree::
:maxdepth: 1
developer-guide
releases
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/development/releases.rst 0000644 0001751 0000173 00000002615 14467657412 021265 0 ustar 00runner docker ===============
Release Process
===============
In order to allow for rapid, predictable releases, Setuptools uses a
mechanical technique for releases, enacted on tagged commits by
continuous integration.
To finalize a release, run ``tox -e finalize``, review, then push
the changes.
If tests pass, the release will be uploaded to PyPI.
Release Frequency
-----------------
Some have asked why Setuptools is released so frequently. Because Setuptools
uses a mechanical release process, it's very easy to make releases whenever the
code is stable (tests are passing). As a result, the philosophy is to release
early and often.
While some find the frequent releases somewhat surprising, they only empower
the user. Although releases are made frequently, users can choose the frequency
at which they use those releases. If instead Setuptools contributions were only
released in batches, the user would be constrained to only use Setuptools when
those official releases were made. With frequent releases, the user can govern
exactly how often he wishes to update.
Frequent releases also then obviate the need for dev or beta releases in most
cases. Because releases are made early and often, bugs are discovered and
corrected quickly, in many cases before other users have yet to encounter them.
Release Managers
----------------
Additionally, anyone with push access to the master branch has access to cut
releases.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/history.rst 0000644 0001751 0000173 00000003555 14467657412 016645 0 ustar 00runner docker :tocdepth: 2
.. _changes:
History
*******
.. towncrier-draft-entries:: DRAFT, unreleased as on |today|
.. include:: ../NEWS (links).rst
Credits
*******
* The original design for the ``.egg`` format and the ``pkg_resources`` API was
co-created by Phillip Eby and Bob Ippolito. Bob also implemented the first
version of ``pkg_resources``, and supplied the macOS operating system version
compatibility algorithm.
* Ian Bicking implemented many early "creature comfort" features of
easy_install, including support for downloading via Sourceforge and
Subversion repositories. Ian's comments on the Web-SIG about WSGI
application deployment also inspired the concept of "entry points" in eggs,
and he has given talks at PyCon and elsewhere to inform and educate the
community about eggs and setuptools.
* Jim Fulton contributed time and effort to build automated tests of various
aspects of ``easy_install``, and supplied the doctests for the command-line
``.exe`` wrappers on Windows.
* Phillip J. Eby is the seminal author of setuptools, and
first proposed the idea of an importable binary distribution format for
Python application plug-ins.
* Significant parts of the implementation of setuptools were funded by the Open
Source Applications Foundation, to provide a plug-in infrastructure for the
Chandler PIM application. In addition, many OSAF staffers (such as Mike
"Code Bear" Taylor) contributed their time and stress as guinea pigs for the
use of eggs and setuptools, even before eggs were "cool". (Thanks, guys!)
* Tarek Ziadé is the principal author of the Distribute fork, which
re-invigorated the community on the project, encouraged renewed innovation,
and addressed many defects.
* Jason R. Coombs performed the merge with Distribute, maintaining the
project for several years in coordination with the Python Packaging
Authority (PyPA).
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/index.rst 0000644 0001751 0000173 00000001530 14467657412 016242 0 ustar 00runner docker .. image:: images/banner-640x320.svg
:align: center
Documentation
=============
Setuptools is a fully-featured, actively-maintained, and stable library
designed to facilitate packaging Python projects.
It helps developers to easily share reusable code (in the form of a library)
and programs (e.g., CLI/GUI tools implemented in Python), that can be installed
with :pypi:`pip` and uploaded to `PyPI `_.
.. sidebar-links::
:home:
:pypi:
.. toctree::
:maxdepth: 1
:hidden:
User guide
build_meta
pkg_resources
references/keywords
setuptools
.. toctree::
:caption: Project
:maxdepth: 1
:hidden:
roadmap
Development guide
Backward compatibility & deprecated practice
Changelog
artwork
.. tidelift-referral-banner::
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/pkg_resources.rst 0000644 0001751 0000173 00000270137 14467657412 020021 0 ustar 00runner docker =============================================================
Package Discovery and Resource Access using ``pkg_resources``
=============================================================
The ``pkg_resources`` module distributed with ``setuptools`` provides an API
for Python libraries to access their resource files, and for extensible
applications and frameworks to automatically discover plugins. It also
provides runtime support for using C extensions that are inside zipfile-format
eggs, support for merging packages that have separately-distributed modules or
subpackages, and APIs for managing Python's current "working set" of active
packages.
.. attention::
Use of ``pkg_resources`` is deprecated in favor of
:mod:`importlib.resources`, :mod:`importlib.metadata`
and their backports (:pypi:`importlib_resources`, :pypi:`importlib_metadata`).
Some useful APIs are also provided by :pypi:`packaging` (e.g. requirements
and version parsing).
Users should refrain from new usage of ``pkg_resources`` and
should work to port to importlib-based solutions.
--------
Overview
--------
The ``pkg_resources`` module provides runtime facilities for finding,
introspecting, activating and using installed Python distributions. Some
of the more advanced features (notably the support for parallel installation
of multiple versions) rely specifically on the "egg" format (either as a
zip archive or subdirectory), while others (such as plugin discovery) will
work correctly so long as "egg-info" metadata directories are available for
relevant distributions.
Eggs are a distribution format for Python modules, similar in concept to
Java's "jars" or Ruby's "gems", or the "wheel" format defined in PEP 427.
However, unlike a pure distribution format, eggs can also be installed and
added directly to ``sys.path`` as an import location. When installed in
this way, eggs are *discoverable*, meaning that they carry metadata that
unambiguously identifies their contents and dependencies. This means that
an installed egg can be *automatically* found and added to ``sys.path`` in
response to simple requests of the form, "get me everything I need to use
docutils' PDF support". This feature allows mutually conflicting versions of
a distribution to co-exist in the same Python installation, with individual
applications activating the desired version at runtime by manipulating the
contents of ``sys.path`` (this differs from the virtual environment
approach, which involves creating isolated environments for each
application).
The following terms are needed in order to explain the capabilities offered
by this module:
project
A library, framework, script, plugin, application, or collection of data
or other resources, or some combination thereof. Projects are assumed to
have "relatively unique" names, e.g. names registered with PyPI.
release
A snapshot of a project at a particular point in time, denoted by a version
identifier.
distribution
A file or files that represent a particular release.
importable distribution
A file or directory that, if placed on ``sys.path``, allows Python to
import any modules contained within it.
pluggable distribution
An importable distribution whose filename unambiguously identifies its
release (i.e. project and version), and whose contents unambiguously
specify what releases of other projects will satisfy its runtime
requirements.
extra
An "extra" is an optional feature of a release, that may impose additional
runtime requirements. For example, if docutils PDF support required a
PDF support library to be present, docutils could define its PDF support as
an "extra", and list what other project releases need to be available in
order to provide it.
environment
A collection of distributions potentially available for importing, but not
necessarily active. More than one distribution (i.e. release version) for
a given project may be present in an environment.
working set
A collection of distributions actually available for importing, as on
``sys.path``. At most one distribution (release version) of a given
project may be present in a working set, as otherwise there would be
ambiguity as to what to import.
eggs
Eggs are pluggable distributions in one of the three formats currently
supported by ``pkg_resources``. There are built eggs, development eggs,
and egg links. Built eggs are directories or zipfiles whose name ends
with ``.egg`` and follows the egg naming conventions, and contain an
``EGG-INFO`` subdirectory (zipped or otherwise). Development eggs are
normal directories of Python code with one or more ``ProjectName.egg-info``
subdirectories. The development egg format is also used to provide a
default version of a distribution that is available to software that
doesn't use ``pkg_resources`` to request specific versions. Egg links
are ``*.egg-link`` files that contain the name of a built or
development egg, to support symbolic linking on platforms that do not
have native symbolic links (or where the symbolic link support is
limited).
(For more information about these terms and concepts, see also this
`architectural overview`_ of ``pkg_resources`` and Python Eggs in general.)
.. _architectural overview: http://mail.python.org/pipermail/distutils-sig/2005-June/004652.html
.. -----------------
.. Developer's Guide
.. -----------------
.. This section isn't written yet. Currently planned topics include
Accessing Resources
Finding and Activating Package Distributions
get_provider()
require()
WorkingSet
iter_distributions
Running Scripts
Configuration
Namespace Packages
Extensible Applications and Frameworks
Locating entry points
Activation listeners
Metadata access
Extended Discovery and Installation
Supporting Custom PEP 302 Implementations
.. For now, please check out the extensive `API Reference`_ below.
-------------
API Reference
-------------
Namespace Package Support
=========================
A namespace package is a package that only contains other packages and modules,
with no direct contents of its own. Such packages can be split across
multiple, separately-packaged distributions. They are normally used to split
up large packages produced by a single organization, such as in the ``zope``
namespace package for Zope Corporation packages, and the ``peak`` namespace
package for the Python Enterprise Application Kit.
To create a namespace package, you list it in the ``namespace_packages``
argument to ``setup()``, in your project's ``setup.py``. (See the
:ref:`setuptools documentation on namespace packages ` for
more information on this.) Also, you must add a ``declare_namespace()`` call
in the package's ``__init__.py`` file(s):
``declare_namespace(name)``
Declare that the dotted package name ``name`` is a "namespace package" whose
contained packages and modules may be spread across multiple distributions.
The named package's ``__path__`` will be extended to include the
corresponding package in all distributions on ``sys.path`` that contain a
package of that name. (More precisely, if an importer's
``find_module(name)`` returns a loader, then it will also be searched for
the package's contents.) Whenever a Distribution's ``activate()`` method
is invoked, it checks for the presence of namespace packages and updates
their ``__path__`` contents accordingly.
Applications that manipulate namespace packages or directly alter ``sys.path``
at runtime may also need to use this API function:
``fixup_namespace_packages(path_item)``
Declare that ``path_item`` is a newly added item on ``sys.path`` that may
need to be used to update existing namespace packages. Ordinarily, this is
called for you when an egg is automatically added to ``sys.path``, but if
your application modifies ``sys.path`` to include locations that may
contain portions of a namespace package, you will need to call this
function to ensure they are added to the existing namespace packages.
Although by default ``pkg_resources`` only supports namespace packages for
filesystem and zip importers, you can extend its support to other "importers"
compatible with PEP 302 using the ``register_namespace_handler()`` function.
See the section below on `Supporting Custom Importers`_ for details.
``WorkingSet`` Objects
======================
The ``WorkingSet`` class provides access to a collection of "active"
distributions. In general, there is only one meaningful ``WorkingSet``
instance: the one that represents the distributions that are currently active
on ``sys.path``. This global instance is available under the name
``working_set`` in the ``pkg_resources`` module. However, specialized
tools may wish to manipulate working sets that don't correspond to
``sys.path``, and therefore may wish to create other ``WorkingSet`` instances.
It's important to note that the global ``working_set`` object is initialized
from ``sys.path`` when ``pkg_resources`` is first imported, but is only updated
if you do all future ``sys.path`` manipulation via ``pkg_resources`` APIs. If
you manually modify ``sys.path``, you must invoke the appropriate methods on
the ``working_set`` instance to keep it in sync. Unfortunately, Python does
not provide any way to detect arbitrary changes to a list object like
``sys.path``, so ``pkg_resources`` cannot automatically update the
``working_set`` based on changes to ``sys.path``.
``WorkingSet(entries=None)``
Create a ``WorkingSet`` from an iterable of path entries. If ``entries``
is not supplied, it defaults to the value of ``sys.path`` at the time
the constructor is called.
Note that you will not normally construct ``WorkingSet`` instances
yourself, but instead you will implicitly or explicitly use the global
``working_set`` instance. For the most part, the ``pkg_resources`` API
is designed so that the ``working_set`` is used by default, such that you
don't have to explicitly refer to it most of the time.
All distributions available directly on ``sys.path`` will be activated
automatically when ``pkg_resources`` is imported. This behaviour can cause
version conflicts for applications which require non-default versions of
those distributions. To handle this situation, ``pkg_resources`` checks for a
``__requires__`` attribute in the ``__main__`` module when initializing the
default working set, and uses this to ensure a suitable version of each
affected distribution is activated. For example::
__requires__ = ["CherryPy < 3"] # Must be set before pkg_resources import
import pkg_resources
Basic ``WorkingSet`` Methods
----------------------------
The following methods of ``WorkingSet`` objects are also available as
module-level functions in ``pkg_resources`` that apply to the default
``working_set`` instance. Thus, you can use e.g. ``pkg_resources.require()``
as an abbreviation for ``pkg_resources.working_set.require()``:
``require(*requirements)``
Ensure that distributions matching ``requirements`` are activated
``requirements`` must be a string or a (possibly-nested) sequence
thereof, specifying the distributions and versions required. The
return value is a sequence of the distributions that needed to be
activated to fulfill the requirements; all relevant distributions are
included, even if they were already activated in this working set.
For the syntax of requirement specifiers, see the section below on
`Requirements Parsing`_.
In general, it should not be necessary for you to call this method
directly. It's intended more for use in quick-and-dirty scripting and
interactive interpreter hacking than for production use. If you're creating
an actual library or application, it's strongly recommended that you create
a "setup.py" script using ``setuptools``, and declare all your requirements
there. That way, tools like pip can automatically detect what requirements
your package has, and deal with them accordingly.
Note that calling ``require('SomePackage')`` will not install
``SomePackage`` if it isn't already present. If you need to do this, you
should use the ``resolve()`` method instead, which allows you to pass an
``installer`` callback that will be invoked when a needed distribution
can't be found on the local machine. You can then have this callback
display a dialog, automatically download the needed distribution, or
whatever else is appropriate for your application. See the documentation
below on the ``resolve()`` method for more information, and also on the
``obtain()`` method of ``Environment`` objects.
``run_script(requires, script_name)``
Locate distribution specified by ``requires`` and run its ``script_name``
script. ``requires`` must be a string containing a requirement specifier.
(See `Requirements Parsing`_ below for the syntax.)
The script, if found, will be executed in *the caller's globals*. That's
because this method is intended to be called from wrapper scripts that
act as a proxy for the "real" scripts in a distribution. A wrapper script
usually doesn't need to do anything but invoke this function with the
correct arguments.
If you need more control over the script execution environment, you
probably want to use the ``run_script()`` method of a ``Distribution``
object's `Metadata API`_ instead.
``iter_entry_points(group, name=None)``
Yield entry point objects from ``group`` matching ``name``
If ``name`` is None, yields all entry points in ``group`` from all
distributions in the working set, otherwise only ones matching both
``group`` and ``name`` are yielded. Entry points are yielded from the active
distributions in the order that the distributions appear in the working
set. (For the global ``working_set``, this should be the same as the order
that they are listed in ``sys.path``.) Note that within the entry points
advertised by an individual distribution, there is no particular ordering.
Please see the section below on `Entry Points`_ for more information.
``WorkingSet`` Methods and Attributes
-------------------------------------
These methods are used to query or manipulate the contents of a specific
working set, so they must be explicitly invoked on a particular ``WorkingSet``
instance:
``add_entry(entry)``
Add a path item to the ``entries``, finding any distributions on it. You
should use this when you add additional items to ``sys.path`` and you want
the global ``working_set`` to reflect the change. This method is also
called by the ``WorkingSet()`` constructor during initialization.
This method uses ``find_distributions(entry,True)`` to find distributions
corresponding to the path entry, and then ``add()`` them. ``entry`` is
always appended to the ``entries`` attribute, even if it is already
present, however. (This is because ``sys.path`` can contain the same value
more than once, and the ``entries`` attribute should be able to reflect
this.)
``__contains__(dist)``
True if ``dist`` is active in this ``WorkingSet``. Note that only one
distribution for a given project can be active in a given ``WorkingSet``.
``__iter__()``
Yield distributions for non-duplicate projects in the working set.
The yield order is the order in which the items' path entries were
added to the working set.
``find(req)``
Find a distribution matching ``req`` (a ``Requirement`` instance).
If there is an active distribution for the requested project, this
returns it, as long as it meets the version requirement specified by
``req``. But, if there is an active distribution for the project and it
does *not* meet the ``req`` requirement, ``VersionConflict`` is raised.
If there is no active distribution for the requested project, ``None``
is returned.
``resolve(requirements, env=None, installer=None)``
List all distributions needed to (recursively) meet ``requirements``
``requirements`` must be a sequence of ``Requirement`` objects. ``env``,
if supplied, should be an ``Environment`` instance. If
not supplied, an ``Environment`` is created from the working set's
``entries``. ``installer``, if supplied, will be invoked with each
requirement that cannot be met by an already-installed distribution; it
should return a ``Distribution`` or ``None``. (See the ``obtain()`` method
of `Environment Objects`_, below, for more information on the ``installer``
argument.)
``add(dist, entry=None)``
Add ``dist`` to working set, associated with ``entry``
If ``entry`` is unspecified, it defaults to ``dist.location``. On exit from
this routine, ``entry`` is added to the end of the working set's ``.entries``
(if it wasn't already present).
``dist`` is only added to the working set if it's for a project that
doesn't already have a distribution active in the set. If it's
successfully added, any callbacks registered with the ``subscribe()``
method will be called. (See `Receiving Change Notifications`_, below.)
Note: ``add()`` is automatically called for you by the ``require()``
method, so you don't normally need to use this method directly.
``entries``
This attribute represents a "shadow" ``sys.path``, primarily useful for
debugging. If you are experiencing import problems, you should check
the global ``working_set`` object's ``entries`` against ``sys.path``, to
ensure that they match. If they do not, then some part of your program
is manipulating ``sys.path`` without updating the ``working_set``
accordingly. IMPORTANT NOTE: do not directly manipulate this attribute!
Setting it equal to ``sys.path`` will not fix your problem, any more than
putting black tape over an "engine warning" light will fix your car! If
this attribute is out of sync with ``sys.path``, it's merely an *indicator*
of the problem, not the cause of it.
Receiving Change Notifications
------------------------------
Extensible applications and frameworks may need to receive notification when
a new distribution (such as a plug-in component) has been added to a working
set. This is what the ``subscribe()`` method and ``add_activation_listener()``
function are for.
``subscribe(callback)``
Invoke ``callback(distribution)`` once for each active distribution that is
in the set now, or gets added later. Because the callback is invoked for
already-active distributions, you do not need to loop over the working set
yourself to deal with the existing items; just register the callback and
be prepared for the fact that it will be called immediately by this method.
Note that callbacks *must not* allow exceptions to propagate, or they will
interfere with the operation of other callbacks and possibly result in an
inconsistent working set state. Callbacks should use a try/except block
to ignore, log, or otherwise process any errors, especially since the code
that caused the callback to be invoked is unlikely to be able to handle
the errors any better than the callback itself.
``pkg_resources.add_activation_listener()`` is an alternate spelling of
``pkg_resources.working_set.subscribe()``.
Locating Plugins
----------------
Extensible applications will sometimes have a "plugin directory" or a set of
plugin directories, from which they want to load entry points or other
metadata. The ``find_plugins()`` method allows you to do this, by scanning an
environment for the newest version of each project that can be safely loaded
without conflicts or missing requirements.
``find_plugins(plugin_env, full_env=None, fallback=True)``
Scan ``plugin_env`` and identify which distributions could be added to this
working set without version conflicts or missing requirements.
Example usage::
distributions, errors = working_set.find_plugins(
Environment(plugin_dirlist)
)
map(working_set.add, distributions) # add plugins+libs to sys.path
print "Couldn't load", errors # display errors
The ``plugin_env`` should be an ``Environment`` instance that contains only
distributions that are in the project's "plugin directory" or directories.
The ``full_env``, if supplied, should be an ``Environment`` instance that
contains all currently-available distributions.
If ``full_env`` is not supplied, one is created automatically from the
``WorkingSet`` this method is called on, which will typically mean that
every directory on ``sys.path`` will be scanned for distributions.
This method returns a 2-tuple: (``distributions``, ``error_info``), where
``distributions`` is a list of the distributions found in ``plugin_env`` that
were loadable, along with any other distributions that are needed to resolve
their dependencies. ``error_info`` is a dictionary mapping unloadable plugin
distributions to an exception instance describing the error that occurred.
Usually this will be a ``DistributionNotFound`` or ``VersionConflict``
instance.
Most applications will use this method mainly on the master ``working_set``
instance in ``pkg_resources``, and then immediately add the returned
distributions to the working set so that they are available on sys.path.
This will make it possible to find any entry points, and allow any other
metadata tracking and hooks to be activated.
The resolution algorithm used by ``find_plugins()`` is as follows. First,
the project names of the distributions present in ``plugin_env`` are sorted.
Then, each project's eggs are tried in descending version order (i.e.,
newest version first).
An attempt is made to resolve each egg's dependencies. If the attempt is
successful, the egg and its dependencies are added to the output list and to
a temporary copy of the working set. The resolution process continues with
the next project name, and no older eggs for that project are tried.
If the resolution attempt fails, however, the error is added to the error
dictionary. If the ``fallback`` flag is true, the next older version of the
plugin is tried, until a working version is found. If false, the resolution
process continues with the next plugin project name.
Some applications may have stricter fallback requirements than others. For
example, an application that has a database schema or persistent objects
may not be able to safely downgrade a version of a package. Others may want
to ensure that a new plugin configuration is either 100% good or else
revert to a known-good configuration. (That is, they may wish to revert to
a known configuration if the ``error_info`` return value is non-empty.)
Note that this algorithm gives precedence to satisfying the dependencies of
alphabetically prior project names in case of version conflicts. If two
projects named "AaronsPlugin" and "ZekesPlugin" both need different versions
of "TomsLibrary", then "AaronsPlugin" will win and "ZekesPlugin" will be
disabled due to version conflict.
``Environment`` Objects
=======================
An "environment" is a collection of ``Distribution`` objects, usually ones
that are present and potentially importable on the current platform.
``Environment`` objects are used by ``pkg_resources`` to index available
distributions during dependency resolution.
``Environment(search_path=None, platform=get_supported_platform(), python=PY_MAJOR)``
Create an environment snapshot by scanning ``search_path`` for distributions
compatible with ``platform`` and ``python``. ``search_path`` should be a
sequence of strings such as might be used on ``sys.path``. If a
``search_path`` isn't supplied, ``sys.path`` is used.
``platform`` is an optional string specifying the name of the platform
that platform-specific distributions must be compatible with. If
unspecified, it defaults to the current platform. ``python`` is an
optional string naming the desired version of Python (e.g. ``'2.4'``);
it defaults to the currently-running version.
You may explicitly set ``platform`` (and/or ``python``) to ``None`` if you
wish to include *all* distributions, not just those compatible with the
running platform or Python version.
Note that ``search_path`` is scanned immediately for distributions, and the
resulting ``Environment`` is a snapshot of the found distributions. It
is not automatically updated if the system's state changes due to e.g.
installation or removal of distributions.
``__getitem__(project_name)``
Returns a list of distributions for the given project name, ordered
from newest to oldest version. (And highest to lowest format precedence
for distributions that contain the same version of the project.) If there
are no distributions for the project, returns an empty list.
``__iter__()``
Yield the unique project names of the distributions in this environment.
The yielded names are always in lower case.
``add(dist)``
Add ``dist`` to the environment if it matches the platform and python version
specified at creation time, and only if the distribution hasn't already
been added. (i.e., adding the same distribution more than once is a no-op.)
``remove(dist)``
Remove ``dist`` from the environment.
``can_add(dist)``
Is distribution ``dist`` acceptable for this environment? If it's not
compatible with the ``platform`` and ``python`` version values specified
when the environment was created, a false value is returned.
``__add__(dist_or_env)`` (``+`` operator)
Add a distribution or environment to an ``Environment`` instance, returning
a *new* environment object that contains all the distributions previously
contained by both. The new environment will have a ``platform`` and
``python`` of ``None``, meaning that it will not reject any distributions
from being added to it; it will simply accept whatever is added. If you
want the added items to be filtered for platform and Python version, or
you want to add them to the *same* environment instance, you should use
in-place addition (``+=``) instead.
``__iadd__(dist_or_env)`` (``+=`` operator)
Add a distribution or environment to an ``Environment`` instance
*in-place*, updating the existing instance and returning it. The
``platform`` and ``python`` filter attributes take effect, so distributions
in the source that do not have a suitable platform string or Python version
are silently ignored.
``best_match(req, working_set, installer=None)``
Find distribution best matching ``req`` and usable on ``working_set``
This calls the ``find(req)`` method of the ``working_set`` to see if a
suitable distribution is already active. (This may raise
``VersionConflict`` if an unsuitable version of the project is already
active in the specified ``working_set``.) If a suitable distribution isn't
active, this method returns the newest distribution in the environment
that meets the ``Requirement`` in ``req``. If no suitable distribution is
found, and ``installer`` is supplied, then the result of calling
the environment's ``obtain(req, installer)`` method will be returned.
``obtain(requirement, installer=None)``
Obtain a distro that matches requirement (e.g. via download). In the
base ``Environment`` class, this routine just returns
``installer(requirement)``, unless ``installer`` is None, in which case
None is returned instead. This method is a hook that allows subclasses
to attempt other ways of obtaining a distribution before falling back
to the ``installer`` argument.
``scan(search_path=None)``
Scan ``search_path`` for distributions usable on ``platform``
Any distributions found are added to the environment. ``search_path`` should
be a sequence of strings such as might be used on ``sys.path``. If not
supplied, ``sys.path`` is used. Only distributions conforming to
the platform/python version defined at initialization are added. This
method is a shortcut for using the ``find_distributions()`` function to
find the distributions from each item in ``search_path``, and then calling
``add()`` to add each one to the environment.
``Requirement`` Objects
=======================
``Requirement`` objects express what versions of a project are suitable for
some purpose. These objects (or their string form) are used by various
``pkg_resources`` APIs in order to find distributions that a script or
distribution needs.
Requirements Parsing
--------------------
``parse_requirements(s)``
Yield ``Requirement`` objects for a string or iterable of lines. Each
requirement must start on a new line. See below for syntax.
``Requirement.parse(s)``
Create a ``Requirement`` object from a string or iterable of lines. A
``ValueError`` is raised if the string or lines do not contain a valid
requirement specifier, or if they contain more than one specifier. (To
parse multiple specifiers from a string or iterable of strings, use
``parse_requirements()`` instead.)
The syntax of a requirement specifier is defined in full in PEP 508.
Some examples of valid requirement specifiers::
FooProject >= 1.2
Fizzy [foo, bar]
PickyThing>1.6,<=1.9,!=1.8.6
SomethingWhoseVersionIDontCareAbout
SomethingWithMarker[foo]>1.0;python_version<"2.7"
The project name is the only required portion of a requirement string, and
if it's the only thing supplied, the requirement will accept any version
of that project.
The "extras" in a requirement are used to request optional features of a
project, that may require additional project distributions in order to
function. For example, if the hypothetical "Report-O-Rama" project offered
optional PDF support, it might require an additional library in order to
provide that support. Thus, a project needing Report-O-Rama's PDF features
could use a requirement of ``Report-O-Rama[PDF]`` to request installation
or activation of both Report-O-Rama and any libraries it needs in order to
provide PDF support. For example, you could use::
pip install Report-O-Rama[PDF]
To install the necessary packages using pip, or call
``pkg_resources.require('Report-O-Rama[PDF]')`` to add the necessary
distributions to sys.path at runtime.
The "markers" in a requirement are used to specify when a requirement
should be installed -- the requirement will be installed if the marker
evaluates as true in the current environment. For example, specifying
``argparse;python_version<"3.0"`` will not install in an Python 3
environment, but will in a Python 2 environment.
``Requirement`` Methods and Attributes
--------------------------------------
``__contains__(dist_or_version)``
Return true if ``dist_or_version`` fits the criteria for this requirement.
If ``dist_or_version`` is a ``Distribution`` object, its project name must
match the requirement's project name, and its version must meet the
requirement's version criteria. If ``dist_or_version`` is a string, it is
parsed using the ``parse_version()`` utility function. Otherwise, it is
assumed to be an already-parsed version.
The ``Requirement`` object's version specifiers (``.specs``) are internally
sorted into ascending version order, and used to establish what ranges of
versions are acceptable. Adjacent redundant conditions are effectively
consolidated (e.g. ``">1, >2"`` produces the same results as ``">2"``, and
``"<2,<3"`` produces the same results as ``"<2"``). ``"!="`` versions are
excised from the ranges they fall within. The version being tested for
acceptability is then checked for membership in the resulting ranges.
``__eq__(other_requirement)``
A requirement compares equal to another requirement if they have
case-insensitively equal project names, version specifiers, and "extras".
(The order that extras and version specifiers are in is also ignored.)
Equal requirements also have equal hashes, so that requirements can be
used in sets or as dictionary keys.
``__str__()``
The string form of a ``Requirement`` is a string that, if passed to
``Requirement.parse()``, would return an equal ``Requirement`` object.
``project_name``
The name of the required project
``key``
An all-lowercase version of the ``project_name``, useful for comparison
or indexing.
``extras``
A tuple of names of "extras" that this requirement calls for. (These will
be all-lowercase and normalized using the ``safe_extra()`` parsing utility
function, so they may not exactly equal the extras the requirement was
created with.)
``specs``
A list of ``(op,version)`` tuples, sorted in ascending parsed-version
order. The ``op`` in each tuple is a comparison operator, represented as
a string. The ``version`` is the (unparsed) version number.
``marker``
An instance of ``packaging.markers.Marker`` that allows evaluation
against the current environment. May be None if no marker specified.
``url``
The location to download the requirement from if specified.
Entry Points
============
Entry points are a simple way for distributions to "advertise" Python objects
(such as functions or classes) for use by other distributions. Extensible
applications and frameworks can search for entry points with a particular name
or group, either from a specific distribution or from all active distributions
on sys.path, and then inspect or load the advertised objects at will.
Entry points belong to "groups" which are named with a dotted name similar to
a Python package or module name. For example, the ``setuptools`` package uses
an entry point named ``distutils.commands`` in order to find commands defined
by distutils extensions. ``setuptools`` treats the names of entry points
defined in that group as the acceptable commands for a setup script.
In a similar way, other packages can define their own entry point groups,
either using dynamic names within the group (like ``distutils.commands``), or
possibly using predefined names within the group. For example, a blogging
framework that offers various pre- or post-publishing hooks might define an
entry point group and look for entry points named "pre_process" and
"post_process" within that group.
To advertise an entry point, a project needs to use ``setuptools`` and provide
an ``entry_points`` argument to ``setup()`` in its setup script, so that the
entry points will be included in the distribution's metadata. For more
details, see :ref:`Advertising Behavior`.
Each project distribution can advertise at most one entry point of a given
name within the same entry point group. For example, a distutils extension
could advertise two different ``distutils.commands`` entry points, as long as
they had different names. However, there is nothing that prevents *different*
projects from advertising entry points of the same name in the same group. In
some cases, this is a desirable thing, since the application or framework that
uses the entry points may be calling them as hooks, or in some other way
combining them. It is up to the application or framework to decide what to do
if multiple distributions advertise an entry point; some possibilities include
using both entry points, displaying an error message, using the first one found
in sys.path order, etc.
Convenience API
---------------
In the following functions, the ``dist`` argument can be a ``Distribution``
instance, a ``Requirement`` instance, or a string specifying a requirement
(i.e. project name, version, etc.). If the argument is a string or
``Requirement``, the specified distribution is located (and added to sys.path
if not already present). An error will be raised if a matching distribution is
not available.
The ``group`` argument should be a string containing a dotted identifier,
identifying an entry point group. If you are defining an entry point group,
you should include some portion of your package's name in the group name so as
to avoid collision with other packages' entry point groups.
``load_entry_point(dist, group, name)``
Load the named entry point from the specified distribution, or raise
``ImportError``.
``get_entry_info(dist, group, name)``
Return an ``EntryPoint`` object for the given ``group`` and ``name`` from
the specified distribution. Returns ``None`` if the distribution has not
advertised a matching entry point.
``get_entry_map(dist, group=None)``
Return the distribution's entry point map for ``group``, or the full entry
map for the distribution. This function always returns a dictionary,
even if the distribution advertises no entry points. If ``group`` is given,
the dictionary maps entry point names to the corresponding ``EntryPoint``
object. If ``group`` is None, the dictionary maps group names to
dictionaries that then map entry point names to the corresponding
``EntryPoint`` instance in that group.
``iter_entry_points(group, name=None)``
Yield entry point objects from ``group`` matching ``name``.
If ``name`` is None, yields all entry points in ``group`` from all
distributions in the working set on sys.path, otherwise only ones matching
both ``group`` and ``name`` are yielded. Entry points are yielded from
the active distributions in the order that the distributions appear on
sys.path. (Within entry points for a particular distribution, however,
there is no particular ordering.)
(This API is actually a method of the global ``working_set`` object; see
the section above on `Basic WorkingSet Methods`_ for more information.)
Creating and Parsing
--------------------
``EntryPoint(name, module_name, attrs=(), extras=(), dist=None)``
Create an ``EntryPoint`` instance. ``name`` is the entry point name. The
``module_name`` is the (dotted) name of the module containing the advertised
object. ``attrs`` is an optional tuple of names to look up from the
module to obtain the advertised object. For example, an ``attrs`` of
``("foo","bar")`` and a ``module_name`` of ``"baz"`` would mean that the
advertised object could be obtained by the following code::
import baz
advertised_object = baz.foo.bar
The ``extras`` are an optional tuple of "extra feature" names that the
distribution needs in order to provide this entry point. When the
entry point is loaded, these extra features are looked up in the ``dist``
argument to find out what other distributions may need to be activated
on sys.path; see the ``load()`` method for more details. The ``extras``
argument is only meaningful if ``dist`` is specified. ``dist`` must be
a ``Distribution`` instance.
``EntryPoint.parse(src, dist=None)`` (classmethod)
Parse a single entry point from string ``src``
Entry point syntax follows the form::
name = some.module:some.attr [extra1,extra2]
The entry name and module name are required, but the ``:attrs`` and
``[extras]`` parts are optional, as is the whitespace shown between
some of the items. The ``dist`` argument is passed through to the
``EntryPoint()`` constructor, along with the other values parsed from
``src``.
``EntryPoint.parse_group(group, lines, dist=None)`` (classmethod)
Parse ``lines`` (a string or sequence of lines) to create a dictionary
mapping entry point names to ``EntryPoint`` objects. ``ValueError`` is
raised if entry point names are duplicated, if ``group`` is not a valid
entry point group name, or if there are any syntax errors. (Note: the
``group`` parameter is used only for validation and to create more
informative error messages.) If ``dist`` is provided, it will be used to
set the ``dist`` attribute of the created ``EntryPoint`` objects.
``EntryPoint.parse_map(data, dist=None)`` (classmethod)
Parse ``data`` into a dictionary mapping group names to dictionaries mapping
entry point names to ``EntryPoint`` objects. If ``data`` is a dictionary,
then the keys are used as group names and the values are passed to
``parse_group()`` as the ``lines`` argument. If ``data`` is a string or
sequence of lines, it is first split into .ini-style sections (using
the ``split_sections()`` utility function) and the section names are used
as group names. In either case, the ``dist`` argument is passed through to
``parse_group()`` so that the entry points will be linked to the specified
distribution.
``EntryPoint`` Objects
----------------------
For simple introspection, ``EntryPoint`` objects have attributes that
correspond exactly to the constructor argument names: ``name``,
``module_name``, ``attrs``, ``extras``, and ``dist`` are all available. In
addition, the following methods are provided:
``load()``
Load the entry point, returning the advertised Python object. Effectively
calls ``self.require()`` then returns ``self.resolve()``.
``require(env=None, installer=None)``
Ensure that any "extras" needed by the entry point are available on
sys.path. ``UnknownExtra`` is raised if the ``EntryPoint`` has ``extras``,
but no ``dist``, or if the named extras are not defined by the
distribution. If ``env`` is supplied, it must be an ``Environment``, and it
will be used to search for needed distributions if they are not already
present on sys.path. If ``installer`` is supplied, it must be a callable
taking a ``Requirement`` instance and returning a matching importable
``Distribution`` instance or None.
``resolve()``
Resolve the entry point from its module and attrs, returning the advertised
Python object. Raises ``ImportError`` if it cannot be obtained.
``__str__()``
The string form of an ``EntryPoint`` is a string that could be passed to
``EntryPoint.parse()`` to produce an equivalent ``EntryPoint``.
``Distribution`` Objects
========================
``Distribution`` objects represent collections of Python code that may or may
not be importable, and may or may not have metadata and resources associated
with them. Their metadata may include information such as what other projects
the distribution depends on, what entry points the distribution advertises, and
so on.
Getting or Creating Distributions
---------------------------------
Most commonly, you'll obtain ``Distribution`` objects from a ``WorkingSet`` or
an ``Environment``. (See the sections above on `WorkingSet Objects`_ and
`Environment Objects`_, which are containers for active distributions and
available distributions, respectively.) You can also obtain ``Distribution``
objects from one of these high-level APIs:
``find_distributions(path_item, only=False)``
Yield distributions accessible via ``path_item``. If ``only`` is true, yield
only distributions whose ``location`` is equal to ``path_item``. In other
words, if ``only`` is true, this yields any distributions that would be
importable if ``path_item`` were on ``sys.path``. If ``only`` is false, this
also yields distributions that are "in" or "under" ``path_item``, but would
not be importable unless their locations were also added to ``sys.path``.
``get_distribution(dist_spec)``
Return a ``Distribution`` object for a given ``Requirement`` or string.
If ``dist_spec`` is already a ``Distribution`` instance, it is returned.
If it is a ``Requirement`` object or a string that can be parsed into one,
it is used to locate and activate a matching distribution, which is then
returned.
However, if you're creating specialized tools for working with distributions,
or creating a new distribution format, you may also need to create
``Distribution`` objects directly, using one of the three constructors below.
These constructors all take an optional ``metadata`` argument, which is used to
access any resources or metadata associated with the distribution. ``metadata``
must be an object that implements the ``IResourceProvider`` interface, or None.
If it is None, an ``EmptyProvider`` is used instead. ``Distribution`` objects
implement both the `IResourceProvider`_ and `IMetadataProvider Methods`_ by
delegating them to the ``metadata`` object.
``Distribution.from_location(location, basename, metadata=None, **kw)`` (classmethod)
Create a distribution for ``location``, which must be a string such as a
URL, filename, or other string that might be used on ``sys.path``.
``basename`` is a string naming the distribution, like ``Foo-1.2-py2.4.egg``.
If ``basename`` ends with ``.egg``, then the project's name, version, python
version and platform are extracted from the filename and used to set those
properties of the created distribution. Any additional keyword arguments
are forwarded to the ``Distribution()`` constructor.
``Distribution.from_filename(filename, metadata=None**kw)`` (classmethod)
Create a distribution by parsing a local filename. This is a shorter way
of saying ``Distribution.from_location(normalize_path(filename),
os.path.basename(filename), metadata)``. In other words, it creates a
distribution whose location is the normalize form of the filename, parsing
name and version information from the base portion of the filename. Any
additional keyword arguments are forwarded to the ``Distribution()``
constructor.
``Distribution(location,metadata,project_name,version,py_version,platform,precedence)``
Create a distribution by setting its properties. All arguments are
optional and default to None, except for ``py_version`` (which defaults to
the current Python version) and ``precedence`` (which defaults to
``EGG_DIST``; for more details see ``precedence`` under `Distribution
Attributes`_ below). Note that it's usually easier to use the
``from_filename()`` or ``from_location()`` constructors than to specify
all these arguments individually.
``Distribution`` Attributes
---------------------------
location
A string indicating the distribution's location. For an importable
distribution, this is the string that would be added to ``sys.path`` to
make it actively importable. For non-importable distributions, this is
simply a filename, URL, or other way of locating the distribution.
project_name
A string, naming the project that this distribution is for. Project names
are defined by a project's setup script, and they are used to identify
projects on PyPI. When a ``Distribution`` is constructed, the
``project_name`` argument is passed through the ``safe_name()`` utility
function to filter out any unacceptable characters.
key
``dist.key`` is short for ``dist.project_name.lower()``. It's used for
case-insensitive comparison and indexing of distributions by project name.
extras
A list of strings, giving the names of extra features defined by the
project's dependency list (the ``extras_require`` argument specified in
the project's setup script).
version
A string denoting what release of the project this distribution contains.
When a ``Distribution`` is constructed, the ``version`` argument is passed
through the ``safe_version()`` utility function to filter out any
unacceptable characters. If no ``version`` is specified at construction
time, then attempting to access this attribute later will cause the
``Distribution`` to try to discover its version by reading its ``PKG-INFO``
metadata file. If ``PKG-INFO`` is unavailable or can't be parsed,
``ValueError`` is raised.
parsed_version
The ``parsed_version`` is an object representing a "parsed" form of the
distribution's ``version``. ``dist.parsed_version`` is a shortcut for
calling ``parse_version(dist.version)``. It is used to compare or sort
distributions by version. (See the `Parsing Utilities`_ section below for
more information on the ``parse_version()`` function.) Note that accessing
``parsed_version`` may result in a ``ValueError`` if the ``Distribution``
was constructed without a ``version`` and without ``metadata`` capable of
supplying the missing version info.
py_version
The major/minor Python version the distribution supports, as a string.
For example, "2.7" or "3.4". The default is the current version of Python.
platform
A string representing the platform the distribution is intended for, or
``None`` if the distribution is "pure Python" and therefore cross-platform.
See `Platform Utilities`_ below for more information on platform strings.
precedence
A distribution's ``precedence`` is used to determine the relative order of
two distributions that have the same ``project_name`` and
``parsed_version``. The default precedence is ``pkg_resources.EGG_DIST``,
which is the highest (i.e. most preferred) precedence. The full list
of predefined precedences, from most preferred to least preferred, is:
``EGG_DIST``, ``BINARY_DIST``, ``SOURCE_DIST``, ``CHECKOUT_DIST``, and
``DEVELOP_DIST``. Normally, precedences other than ``EGG_DIST`` are used
only by the ``setuptools.package_index`` module, when sorting distributions
found in a package index to determine their suitability for installation.
"System" and "Development" eggs (i.e., ones that use the ``.egg-info``
format), however, are automatically given a precedence of ``DEVELOP_DIST``.
``Distribution`` Methods
------------------------
``activate(path=None)``
Ensure distribution is importable on ``path``. If ``path`` is None,
``sys.path`` is used instead. This ensures that the distribution's
``location`` is in the ``path`` list, and it also performs any necessary
namespace package fixups or declarations. (That is, if the distribution
contains namespace packages, this method ensures that they are declared,
and that the distribution's contents for those namespace packages are
merged with the contents provided by any other active distributions. See
the section above on `Namespace Package Support`_ for more information.)
``pkg_resources`` adds a notification callback to the global ``working_set``
that ensures this method is called whenever a distribution is added to it.
Therefore, you should not normally need to explicitly call this method.
(Note that this means that namespace packages on ``sys.path`` are always
imported as soon as ``pkg_resources`` is, which is another reason why
namespace packages should not contain any code or import statements.)
``as_requirement()``
Return a ``Requirement`` instance that matches this distribution's project
name and version.
``requires(extras=())``
List the ``Requirement`` objects that specify this distribution's
dependencies. If ``extras`` is specified, it should be a sequence of names
of "extras" defined by the distribution, and the list returned will then
include any dependencies needed to support the named "extras".
``clone(**kw)``
Create a copy of the distribution. Any supplied keyword arguments override
the corresponding argument to the ``Distribution()`` constructor, allowing
you to change some of the copied distribution's attributes.
``egg_name()``
Return what this distribution's standard filename should be, not including
the ".egg" extension. For example, a distribution for project "Foo"
version 1.2 that runs on Python 2.3 for Windows would have an ``egg_name()``
of ``Foo-1.2-py2.3-win32``. Any dashes in the name or version are
converted to underscores. (``Distribution.from_location()`` will convert
them back when parsing a ".egg" file name.)
``__cmp__(other)``, ``__hash__()``
Distribution objects are hashed and compared on the basis of their parsed
version and precedence, followed by their key (lowercase project name),
location, Python version, and platform.
The following methods are used to access ``EntryPoint`` objects advertised
by the distribution. See the section above on `Entry Points`_ for more
detailed information about these operations:
``get_entry_info(group, name)``
Return the ``EntryPoint`` object for ``group`` and ``name``, or None if no
such point is advertised by this distribution.
``get_entry_map(group=None)``
Return the entry point map for ``group``. If ``group`` is None, return
a dictionary mapping group names to entry point maps for all groups.
(An entry point map is a dictionary of entry point names to ``EntryPoint``
objects.)
``load_entry_point(group, name)``
Short for ``get_entry_info(group, name).load()``. Returns the object
advertised by the named entry point, or raises ``ImportError`` if
the entry point isn't advertised by this distribution, or there is some
other import problem.
In addition to the above methods, ``Distribution`` objects also implement all
of the `IResourceProvider`_ and `IMetadataProvider Methods`_ (which are
documented in later sections):
* ``has_metadata(name)``
* ``metadata_isdir(name)``
* ``metadata_listdir(name)``
* ``get_metadata(name)``
* ``get_metadata_lines(name)``
* ``run_script(script_name, namespace)``
* ``get_resource_filename(manager, resource_name)``
* ``get_resource_stream(manager, resource_name)``
* ``get_resource_string(manager, resource_name)``
* ``has_resource(resource_name)``
* ``resource_isdir(resource_name)``
* ``resource_listdir(resource_name)``
If the distribution was created with a ``metadata`` argument, these resource and
metadata access methods are all delegated to that ``metadata`` provider.
Otherwise, they are delegated to an ``EmptyProvider``, so that the distribution
will appear to have no resources or metadata. This delegation approach is used
so that supporting custom importers or new distribution formats can be done
simply by creating an appropriate `IResourceProvider`_ implementation; see the
section below on `Supporting Custom Importers`_ for more details.
.. _ResourceManager API:
``ResourceManager`` API
=======================
The ``ResourceManager`` class provides uniform access to package resources,
whether those resources exist as files and directories or are compressed in
an archive of some kind.
Normally, you do not need to create or explicitly manage ``ResourceManager``
instances, as the ``pkg_resources`` module creates a global instance for you,
and makes most of its methods available as top-level names in the
``pkg_resources`` module namespace. So, for example, this code actually
calls the ``resource_string()`` method of the global ``ResourceManager``::
import pkg_resources
my_data = pkg_resources.resource_string(__name__, "foo.dat")
Thus, you can use the APIs below without needing an explicit
``ResourceManager`` instance; just import and use them as needed.
Basic Resource Access
---------------------
In the following methods, the ``package_or_requirement`` argument may be either
a Python package/module name (e.g. ``foo.bar``) or a ``Requirement`` instance.
If it is a package or module name, the named module or package must be
importable (i.e., be in a distribution or directory on ``sys.path``), and the
``resource_name`` argument is interpreted relative to the named package. (Note
that if a module name is used, then the resource name is relative to the
package immediately containing the named module. Also, you should not use use
a namespace package name, because a namespace package can be spread across
multiple distributions, and is therefore ambiguous as to which distribution
should be searched for the resource.)
If it is a ``Requirement``, then the requirement is automatically resolved
(searching the current ``Environment`` if necessary) and a matching
distribution is added to the ``WorkingSet`` and ``sys.path`` if one was not
already present. (Unless the ``Requirement`` can't be satisfied, in which
case an exception is raised.) The ``resource_name`` argument is then interpreted
relative to the root of the identified distribution; i.e. its first path
segment will be treated as a peer of the top-level modules or packages in the
distribution.
Note that resource names must be ``/``-separated paths rooted at the package,
cannot contain relative names like ``".."``, and cannot be absolute. Do *not* use
``os.path`` routines to manipulate resource paths, as they are *not* filesystem
paths.
``resource_exists(package_or_requirement, resource_name)``
Does the named resource exist? Return ``True`` or ``False`` accordingly.
``resource_stream(package_or_requirement, resource_name)``
Return a readable file-like object for the specified resource; it may be
an actual file, a ``StringIO``, or some similar object. The stream is
in "binary mode", in the sense that whatever bytes are in the resource
will be read as-is.
``resource_string(package_or_requirement, resource_name)``
Return the specified resource as ``bytes``. The resource is read in
binary fashion, such that the returned string contains exactly the bytes
that are stored in the resource.
``resource_isdir(package_or_requirement, resource_name)``
Is the named resource a directory? Return ``True`` or ``False``
accordingly.
``resource_listdir(package_or_requirement, resource_name)``
List the contents of the named resource directory, just like ``os.listdir``
except that it works even if the resource is in a zipfile.
Note that only ``resource_exists()`` and ``resource_isdir()`` are insensitive
as to the resource type. You cannot use ``resource_listdir()`` on a file
resource, and you can't use ``resource_string()`` or ``resource_stream()`` on
directory resources. Using an inappropriate method for the resource type may
result in an exception or undefined behavior, depending on the platform and
distribution format involved.
Resource Extraction
-------------------
``resource_filename(package_or_requirement, resource_name)``
Sometimes, it is not sufficient to access a resource in string or stream
form, and a true filesystem filename is needed. In such cases, you can
use this method (or module-level function) to obtain a filename for a
resource. If the resource is in an archive distribution (such as a zipped
egg), it will be extracted to a cache directory, and the filename within
the cache will be returned. If the named resource is a directory, then
all resources within that directory (including subdirectories) are also
extracted. If the named resource is a C extension or "eager resource"
(see the ``setuptools`` documentation for details), then all C extensions
and eager resources are extracted at the same time.
Archived resources are extracted to a cache location that can be managed by
the following two methods:
``set_extraction_path(path)``
Set the base path where resources will be extracted to, if needed.
If you do not call this routine before any extractions take place, the
path defaults to the return value of ``get_default_cache()``. (Which is
based on the ``PYTHON_EGG_CACHE`` environment variable, with various
platform-specific fallbacks. See that routine's documentation for more
details.)
Resources are extracted to subdirectories of this path based upon
information given by the resource provider. You may set this to a
temporary directory, but then you must call ``cleanup_resources()`` to
delete the extracted files when done. There is no guarantee that
``cleanup_resources()`` will be able to remove all extracted files. (On
Windows, for example, you can't unlink .pyd or .dll files that are still
in use.)
Note that you may not change the extraction path for a given resource
manager once resources have been extracted, unless you first call
``cleanup_resources()``.
``cleanup_resources(force=False)``
Delete all extracted resource files and directories, returning a list
of the file and directory names that could not be successfully removed.
This function does not have any concurrency protection, so it should
generally only be called when the extraction path is a temporary
directory exclusive to a single process. This method is not
automatically called; you must call it explicitly or register it as an
``atexit`` function if you wish to ensure cleanup of a temporary
directory used for extractions.
"Provider" Interface
--------------------
If you are implementing an ``IResourceProvider`` and/or ``IMetadataProvider``
for a new distribution archive format, you may need to use the following
``IResourceManager`` methods to coordinate extraction of resources to the
filesystem. If you're not implementing an archive format, however, you have
no need to use these methods. Unlike the other methods listed above, they are
*not* available as top-level functions tied to the global ``ResourceManager``;
you must therefore have an explicit ``ResourceManager`` instance to use them.
``get_cache_path(archive_name, names=())``
Return absolute location in cache for ``archive_name`` and ``names``
The parent directory of the resulting path will be created if it does
not already exist. ``archive_name`` should be the base filename of the
enclosing egg (which may not be the name of the enclosing zipfile!),
including its ".egg" extension. ``names``, if provided, should be a
sequence of path name parts "under" the egg's extraction location.
This method should only be called by resource providers that need to
obtain an extraction location, and only for names they intend to
extract, as it tracks the generated names for possible cleanup later.
``extraction_error()``
Raise an ``ExtractionError`` describing the active exception as interfering
with the extraction process. You should call this if you encounter any
OS errors extracting the file to the cache path; it will format the
operating system exception for you, and add other information to the
``ExtractionError`` instance that may be needed by programs that want to
wrap or handle extraction errors themselves.
``postprocess(tempname, filename)``
Perform any platform-specific postprocessing of ``tempname``.
Resource providers should call this method ONLY after successfully
extracting a compressed resource. They must NOT call it on resources
that are already in the filesystem.
``tempname`` is the current (temporary) name of the file, and ``filename``
is the name it will be renamed to by the caller after this routine
returns.
Metadata API
============
The metadata API is used to access metadata resources bundled in a pluggable
distribution. Metadata resources are virtual files or directories containing
information about the distribution, such as might be used by an extensible
application or framework to connect "plugins". Like other kinds of resources,
metadata resource names are ``/``-separated and should not contain ``..`` or
begin with a ``/``. You should not use ``os.path`` routines to manipulate
resource paths.
The metadata API is provided by objects implementing the ``IMetadataProvider``
or ``IResourceProvider`` interfaces. ``Distribution`` objects implement this
interface, as do objects returned by the ``get_provider()`` function:
``get_provider(package_or_requirement)``
If a package name is supplied, return an ``IResourceProvider`` for the
package. If a ``Requirement`` is supplied, resolve it by returning a
``Distribution`` from the current working set (searching the current
``Environment`` if necessary and adding the newly found ``Distribution``
to the working set). If the named package can't be imported, or the
``Requirement`` can't be satisfied, an exception is raised.
NOTE: if you use a package name rather than a ``Requirement``, the object
you get back may not be a pluggable distribution, depending on the method
by which the package was installed. In particular, "development" packages
and "single-version externally-managed" packages do not have any way to
map from a package name to the corresponding project's metadata. Do not
write code that passes a package name to ``get_provider()`` and then tries
to retrieve project metadata from the returned object. It may appear to
work when the named package is in an ``.egg`` file or directory, but
it will fail in other installation scenarios. If you want project
metadata, you need to ask for a *project*, not a package.
``IMetadataProvider`` Methods
-----------------------------
The methods provided by objects (such as ``Distribution`` instances) that
implement the ``IMetadataProvider`` or ``IResourceProvider`` interfaces are:
``has_metadata(name)``
Does the named metadata resource exist?
``metadata_isdir(name)``
Is the named metadata resource a directory?
``metadata_listdir(name)``
List of metadata names in the directory (like ``os.listdir()``)
``get_metadata(name)``
Return the named metadata resource as a string. The data is read in binary
mode; i.e., the exact bytes of the resource file are returned.
``get_metadata_lines(name)``
Yield named metadata resource as list of non-blank non-comment lines. This
is short for calling ``yield_lines(provider.get_metadata(name))``. See the
section on `yield_lines()`_ below for more information on the syntax it
recognizes.
``run_script(script_name, namespace)``
Execute the named script in the supplied namespace dictionary. Raises
``ResolutionError`` if there is no script by that name in the ``scripts``
metadata directory. ``namespace`` should be a Python dictionary, usually
a module dictionary if the script is being run as a module.
Exceptions
==========
``pkg_resources`` provides a simple exception hierarchy for problems that may
occur when processing requests to locate and activate packages::
ResolutionError
DistributionNotFound
VersionConflict
UnknownExtra
ExtractionError
``ResolutionError``
This class is used as a base class for the other three exceptions, so that
you can catch all of them with a single "except" clause. It is also raised
directly for miscellaneous requirement-resolution problems like trying to
run a script that doesn't exist in the distribution it was requested from.
``DistributionNotFound``
A distribution needed to fulfill a requirement could not be found.
``VersionConflict``
The requested version of a project conflicts with an already-activated
version of the same project.
``UnknownExtra``
One of the "extras" requested was not recognized by the distribution it
was requested from.
``ExtractionError``
A problem occurred extracting a resource to the Python Egg cache. The
following attributes are available on instances of this exception:
manager
The resource manager that raised this exception
cache_path
The base directory for resource extraction
original_error
The exception instance that caused extraction to fail
Supporting Custom Importers
===========================
By default, ``pkg_resources`` supports normal filesystem imports, and
``zipimport`` importers. If you wish to use the ``pkg_resources`` features
with other (PEP 302-compatible) importers or module loaders, you may need to
register various handlers and support functions using these APIs:
``register_finder(importer_type, distribution_finder)``
Register ``distribution_finder`` to find distributions in ``sys.path`` items.
``importer_type`` is the type or class of a PEP 302 "Importer" (``sys.path``
item handler), and ``distribution_finder`` is a callable that, when passed a
path item, the importer instance, and an ``only`` flag, yields
``Distribution`` instances found under that path item. (The ``only`` flag,
if true, means the finder should yield only ``Distribution`` objects whose
``location`` is equal to the path item provided.)
See the source of the ``pkg_resources.find_on_path`` function for an
example finder function.
``register_loader_type(loader_type, provider_factory)``
Register ``provider_factory`` to make ``IResourceProvider`` objects for
``loader_type``. ``loader_type`` is the type or class of a PEP 302
``module.__loader__``, and ``provider_factory`` is a function that, when
passed a module object, returns an `IResourceProvider`_ for that module,
allowing it to be used with the `ResourceManager API`_.
``register_namespace_handler(importer_type, namespace_handler)``
Register ``namespace_handler`` to declare namespace packages for the given
``importer_type``. ``importer_type`` is the type or class of a PEP 302
"importer" (sys.path item handler), and ``namespace_handler`` is a callable
with a signature like this::
def namespace_handler(importer, path_entry, moduleName, module):
# return a path_entry to use for child packages
Namespace handlers are only called if the relevant importer object has
already agreed that it can handle the relevant path item. The handler
should only return a subpath if the module ``__path__`` does not already
contain an equivalent subpath. Otherwise, it should return None.
For an example namespace handler, see the source of the
``pkg_resources.file_ns_handler`` function, which is used for both zipfile
importing and regular importing.
IResourceProvider
-----------------
``IResourceProvider`` is an abstract class that documents what methods are
required of objects returned by a ``provider_factory`` registered with
``register_loader_type()``. ``IResourceProvider`` is a subclass of
``IMetadataProvider``, so objects that implement this interface must also
implement all of the `IMetadataProvider Methods`_ as well as the methods
shown here. The ``manager`` argument to the methods below must be an object
that supports the full `ResourceManager API`_ documented above.
``get_resource_filename(manager, resource_name)``
Return a true filesystem path for ``resource_name``, coordinating the
extraction with ``manager``, if the resource must be unpacked to the
filesystem.
``get_resource_stream(manager, resource_name)``
Return a readable file-like object for ``resource_name``.
``get_resource_string(manager, resource_name)``
Return a string containing the contents of ``resource_name``.
``has_resource(resource_name)``
Does the package contain the named resource?
``resource_isdir(resource_name)``
Is the named resource a directory? Return a false value if the resource
does not exist or is not a directory.
``resource_listdir(resource_name)``
Return a list of the contents of the resource directory, ala
``os.listdir()``. Requesting the contents of a non-existent directory may
raise an exception.
Note, by the way, that your provider classes need not (and should not) subclass
``IResourceProvider`` or ``IMetadataProvider``! These classes exist solely
for documentation purposes and do not provide any useful implementation code.
You may instead wish to subclass one of the `built-in resource providers`_.
Built-in Resource Providers
---------------------------
``pkg_resources`` includes several provider classes that are automatically used
where appropriate. Their inheritance tree looks like this::
NullProvider
EggProvider
DefaultProvider
PathMetadata
ZipProvider
EggMetadata
EmptyProvider
FileMetadata
``NullProvider``
This provider class is just an abstract base that provides for common
provider behaviors (such as running scripts), given a definition for just
a few abstract methods.
``EggProvider``
This provider class adds in some egg-specific features that are common
to zipped and unzipped eggs.
``DefaultProvider``
This provider class is used for unpacked eggs and "plain old Python"
filesystem modules.
``ZipProvider``
This provider class is used for all zipped modules, whether they are eggs
or not.
``EmptyProvider``
This provider class always returns answers consistent with a provider that
has no metadata or resources. ``Distribution`` objects created without
a ``metadata`` argument use an instance of this provider class instead.
Since all ``EmptyProvider`` instances are equivalent, there is no need
to have more than one instance. ``pkg_resources`` therefore creates a
global instance of this class under the name ``empty_provider``, and you
may use it if you have need of an ``EmptyProvider`` instance.
``PathMetadata(path, egg_info)``
Create an ``IResourceProvider`` for a filesystem-based distribution, where
``path`` is the filesystem location of the importable modules, and ``egg_info``
is the filesystem location of the distribution's metadata directory.
``egg_info`` should usually be the ``EGG-INFO`` subdirectory of ``path`` for an
"unpacked egg", and a ``ProjectName.egg-info`` subdirectory of ``path`` for
a "development egg". However, other uses are possible for custom purposes.
``EggMetadata(zipimporter)``
Create an ``IResourceProvider`` for a zipfile-based distribution. The
``zipimporter`` should be a ``zipimport.zipimporter`` instance, and may
represent a "basket" (a zipfile containing multiple ".egg" subdirectories)
a specific egg *within* a basket, or a zipfile egg (where the zipfile
itself is a ".egg"). It can also be a combination, such as a zipfile egg
that also contains other eggs.
``FileMetadata(path_to_pkg_info)``
Create an ``IResourceProvider`` that provides exactly one metadata
resource: ``PKG-INFO``. The supplied path should be a distutils PKG-INFO
file. This is basically the same as an ``EmptyProvider``, except that
requests for ``PKG-INFO`` will be answered using the contents of the
designated file. (This provider is used to wrap ``.egg-info`` files
installed by vendor-supplied system packages.)
Utility Functions
=================
In addition to its high-level APIs, ``pkg_resources`` also includes several
generally-useful utility routines. These routines are used to implement the
high-level APIs, but can also be quite useful by themselves.
Parsing Utilities
-----------------
``parse_version(version)``
Parsed a project's version string as defined by PEP 440. The returned
value will be an object that represents the version. These objects may
be compared to each other and sorted. The sorting algorithm is as defined
by PEP 440 with the addition that any version which is not a valid PEP 440
version will be considered less than any valid PEP 440 version and the
invalid versions will continue sorting using the original algorithm.
.. _yield_lines():
``yield_lines(strs)``
Yield non-empty/non-comment lines from a string/unicode or a
possibly-nested sequence thereof. If ``strs`` is an instance of
``basestring``, it is split into lines, and each non-blank, non-comment
line is yielded after stripping leading and trailing whitespace. (Lines
whose first non-blank character is ``#`` are considered comment lines.)
If ``strs`` is not an instance of ``basestring``, it is iterated over, and
each item is passed recursively to ``yield_lines()``, so that an arbitrarily
nested sequence of strings, or sequences of sequences of strings can be
flattened out to the lines contained therein. So for example, passing
a file object or a list of strings to ``yield_lines`` will both work.
(Note that between each string in a sequence of strings there is assumed to
be an implicit line break, so lines cannot bridge two strings in a
sequence.)
This routine is used extensively by ``pkg_resources`` to parse metadata
and file formats of various kinds, and most other ``pkg_resources``
parsing functions that yield multiple values will use it to break up their
input. However, this routine is idempotent, so calling ``yield_lines()``
on the output of another call to ``yield_lines()`` is completely harmless.
``split_sections(strs)``
Split a string (or possibly-nested iterable thereof), yielding ``(section,
content)`` pairs found using an ``.ini``-like syntax. Each ``section`` is
a whitespace-stripped version of the section name ("``[section]``")
and each ``content`` is a list of stripped lines excluding blank lines and
comment-only lines. If there are any non-blank, non-comment lines before
the first section header, they're yielded in a first ``section`` of
``None``.
This routine uses ``yield_lines()`` as its front end, so you can pass in
anything that ``yield_lines()`` accepts, such as an open text file, string,
or sequence of strings. ``ValueError`` is raised if a malformed section
header is found (i.e. a line starting with ``[`` but not ending with
``]``).
Note that this simplistic parser assumes that any line whose first nonblank
character is ``[`` is a section heading, so it can't support .ini format
variations that allow ``[`` as the first nonblank character on other lines.
``safe_name(name)``
Return a "safe" form of a project's name, suitable for use in a
``Requirement`` string, as a distribution name, or a PyPI project name.
All non-alphanumeric runs are condensed to single "-" characters, such that
a name like "The $$$ Tree" becomes "The-Tree". Note that if you are
generating a filename from this value you should combine it with a call to
``to_filename()`` so all dashes ("-") are replaced by underscores ("_").
See ``to_filename()``.
``safe_version(version)``
This will return the normalized form of any PEP 440 version. If the version
string is not PEP 440 compatible, this function behaves similar to
``safe_name()`` except that spaces in the input become dots, and dots are
allowed to exist in the output. As with ``safe_name()``, if you are
generating a filename from this you should replace any "-" characters in
the output with underscores.
``safe_extra(extra)``
Return a "safe" form of an extra's name, suitable for use in a requirement
string or a setup script's ``extras_require`` keyword. This routine is
similar to ``safe_name()`` except that non-alphanumeric runs are replaced
by a single underbar (``_``), and the result is lowercased.
``to_filename(name_or_version)``
Escape a name or version string so it can be used in a dash-separated
filename (or ``#egg=name-version`` tag) without ambiguity. You
should only pass in values that were returned by ``safe_name()`` or
``safe_version()``.
Platform Utilities
------------------
``get_build_platform()``
Return this platform's identifier string. For Windows, the return value
is ``"win32"``, and for macOS it is a string of the form
``"macosx-10.4-ppc"``. All other platforms return the same uname-based
string that the ``distutils.util.get_platform()`` function returns.
This string is the minimum platform version required by distributions built
on the local machine. (Backward compatibility note: setuptools versions
prior to 0.6b1 called this function ``get_platform()``, and the function is
still available under that name for backward compatibility reasons.)
``get_supported_platform()`` (New in 0.6b1)
This is the similar to ``get_build_platform()``, but is the maximum
platform version that the local machine supports. You will usually want
to use this value as the ``provided`` argument to the
``compatible_platforms()`` function.
``compatible_platforms(provided, required)``
Return true if a distribution built on the ``provided`` platform may be used
on the ``required`` platform. If either platform value is ``None``, it is
considered a wildcard, and the platforms are therefore compatible.
Likewise, if the platform strings are equal, they're also considered
compatible, and ``True`` is returned. Currently, the only non-equal
platform strings that are considered compatible are macOS platform
strings with the same hardware type (e.g. ``ppc``) and major version
(e.g. ``10``) with the ``provided`` platform's minor version being less than
or equal to the ``required`` platform's minor version.
``get_default_cache()``
Determine the default cache location for extracting resources from zipped
eggs. This routine returns the ``PYTHON_EGG_CACHE`` environment variable,
if set. Otherwise, on Windows, it returns a "Python-Eggs" subdirectory of
the user's "Application Data" directory. On all other systems, it returns
``os.path.expanduser("~/.python-eggs")`` if ``PYTHON_EGG_CACHE`` is not
set.
PEP 302 Utilities
-----------------
``get_importer(path_item)``
A deprecated alias for ``pkgutil.get_importer()``
File/Path Utilities
-------------------
``ensure_directory(path)``
Ensure that the parent directory (``os.path.dirname``) of ``path`` actually
exists, using ``os.makedirs()`` if necessary.
``normalize_path(path)``
Return a "normalized" version of ``path``, such that two paths represent
the same filesystem location if they have equal ``normalized_path()``
values. Specifically, this is a shortcut for calling ``os.path.realpath``
and ``os.path.normcase`` on ``path``. Unfortunately, on certain platforms
(notably Cygwin and macOS) the ``normcase`` function does not accurately
reflect the platform's case-sensitivity, so there is always the possibility
of two apparently-different paths being equal on such platforms.
History
-------
0.6c9
* Fix ``resource_listdir('')`` always returning an empty list for zipped eggs.
0.6c7
* Fix package precedence problem where single-version eggs installed in
``site-packages`` would take precedence over ``.egg`` files (or directories)
installed in ``site-packages``.
0.6c6
* Fix extracted C extensions not having executable permissions under Cygwin.
* Allow ``.egg-link`` files to contain relative paths.
* Fix cache dir defaults on Windows when multiple environment vars are needed
to construct a path.
0.6c4
* Fix "dev" versions being considered newer than release candidates.
0.6c3
* Python 2.5 compatibility fixes.
0.6c2
* Fix a problem with eggs specified directly on ``PYTHONPATH`` on
case-insensitive filesystems possibly not showing up in the default
working set, due to differing normalizations of ``sys.path`` entries.
0.6b3
* Fixed a duplicate path insertion problem on case-insensitive filesystems.
0.6b1
* Split ``get_platform()`` into ``get_supported_platform()`` and
``get_build_platform()`` to work around a Mac versioning problem that caused
the behavior of ``compatible_platforms()`` to be platform specific.
* Fix entry point parsing when a standalone module name has whitespace
between it and the extras.
0.6a11
* Added ``ExtractionError`` and ``ResourceManager.extraction_error()`` so that
cache permission problems get a more user-friendly explanation of the
problem, and so that programs can catch and handle extraction errors if they
need to.
0.6a10
* Added the ``extras`` attribute to ``Distribution``, the ``find_plugins()``
method to ``WorkingSet``, and the ``__add__()`` and ``__iadd__()`` methods
to ``Environment``.
* ``safe_name()`` now allows dots in project names.
* There is a new ``to_filename()`` function that escapes project names and
versions for safe use in constructing egg filenames from a Distribution
object's metadata.
* Added ``Distribution.clone()`` method, and keyword argument support to other
``Distribution`` constructors.
* Added the ``DEVELOP_DIST`` precedence, and automatically assign it to
eggs using ``.egg-info`` format.
0.6a9
* Don't raise an error when an invalid (unfinished) distribution is found
unless absolutely necessary. Warn about skipping invalid/unfinished eggs
when building an Environment.
* Added support for ``.egg-info`` files or directories with version/platform
information embedded in the filename, so that system packagers have the
option of including ``PKG-INFO`` files to indicate the presence of a
system-installed egg, without needing to use ``.egg`` directories, zipfiles,
or ``.pth`` manipulation.
* Changed ``parse_version()`` to remove dashes before pre-release tags, so
that ``0.2-rc1`` is considered an *older* version than ``0.2``, and is equal
to ``0.2rc1``. The idea that a dash *always* meant a post-release version
was highly non-intuitive to setuptools users and Python developers, who
seem to want to use ``-rc`` version numbers a lot.
0.6a8
* Fixed a problem with ``WorkingSet.resolve()`` that prevented version
conflicts from being detected at runtime.
* Improved runtime conflict warning message to identify a line in the user's
program, rather than flagging the ``warn()`` call in ``pkg_resources``.
* Avoid giving runtime conflict warnings for namespace packages, even if they
were declared by a different package than the one currently being activated.
* Fix path insertion algorithm for case-insensitive filesystems.
* Fixed a problem with nested namespace packages (e.g. ``peak.util``) not
being set as an attribute of their parent package.
0.6a6
* Activated distributions are now inserted in ``sys.path`` (and the working
set) just before the directory that contains them, instead of at the end.
This allows e.g. eggs in ``site-packages`` to override unmanaged modules in
the same location, and allows eggs found earlier on ``sys.path`` to override
ones found later.
* When a distribution is activated, it now checks whether any contained
non-namespace modules have already been imported and issues a warning if
a conflicting module has already been imported.
* Changed dependency processing so that it's breadth-first, allowing a
depender's preferences to override those of a dependee, to prevent conflicts
when a lower version is acceptable to the dependee, but not the depender.
* Fixed a problem extracting zipped files on Windows, when the egg in question
has had changed contents but still has the same version number.
0.6a4
* Fix a bug in ``WorkingSet.resolve()`` that was introduced in 0.6a3.
0.6a3
* Added ``safe_extra()`` parsing utility routine, and use it for Requirement,
EntryPoint, and Distribution objects' extras handling.
0.6a1
* Enhanced performance of ``require()`` and related operations when all
requirements are already in the working set, and enhanced performance of
directory scanning for distributions.
* Fixed some problems using ``pkg_resources`` w/PEP 302 loaders other than
``zipimport``, and the previously-broken "eager resource" support.
* Fixed ``pkg_resources.resource_exists()`` not working correctly, along with
some other resource API bugs.
* Many API changes and enhancements:
* Added ``EntryPoint``, ``get_entry_map``, ``load_entry_point``, and
``get_entry_info`` APIs for dynamic plugin discovery.
* ``list_resources`` is now ``resource_listdir`` (and it actually works)
* Resource API functions like ``resource_string()`` that accepted a package
name and resource name, will now also accept a ``Requirement`` object in
place of the package name (to allow access to non-package data files in
an egg).
* ``get_provider()`` will now accept a ``Requirement`` instance or a module
name. If it is given a ``Requirement``, it will return a corresponding
``Distribution`` (by calling ``require()`` if a suitable distribution
isn't already in the working set), rather than returning a metadata and
resource provider for a specific module. (The difference is in how
resource paths are interpreted; supplying a module name means resources
path will be module-relative, rather than relative to the distribution's
root.)
* ``Distribution`` objects now implement the ``IResourceProvider`` and
``IMetadataProvider`` interfaces, so you don't need to reference the (no
longer available) ``metadata`` attribute to get at these interfaces.
* ``Distribution`` and ``Requirement`` both have a ``project_name``
attribute for the project name they refer to. (Previously these were
``name`` and ``distname`` attributes.)
* The ``path`` attribute of ``Distribution`` objects is now ``location``,
because it isn't necessarily a filesystem path (and hasn't been for some
time now). The ``location`` of ``Distribution`` objects in the filesystem
should always be normalized using ``pkg_resources.normalize_path()``; all
of the setuptools' code that generates distributions from the filesystem
(including ``Distribution.from_filename()``) ensure this invariant, but if
you use a more generic API like ``Distribution()`` or
``Distribution.from_location()`` you should take care that you don't
create a distribution with an un-normalized filesystem path.
* ``Distribution`` objects now have an ``as_requirement()`` method that
returns a ``Requirement`` for the distribution's project name and version.
* Distribution objects no longer have an ``installed_on()`` method, and the
``install_on()`` method is now ``activate()`` (but may go away altogether
soon). The ``depends()`` method has also been renamed to ``requires()``,
and ``InvalidOption`` is now ``UnknownExtra``.
* ``find_distributions()`` now takes an additional argument called ``only``,
that tells it to only yield distributions whose location is the passed-in
path. (It defaults to False, so that the default behavior is unchanged.)
* ``AvailableDistributions`` is now called ``Environment``, and the
``get()``, ``__len__()``, and ``__contains__()`` methods were removed,
because they weren't particularly useful. ``__getitem__()`` no longer
raises ``KeyError``; it just returns an empty list if there are no
distributions for the named project.
* The ``resolve()`` method of ``Environment`` is now a method of
``WorkingSet`` instead, and the ``best_match()`` method now uses a working
set instead of a path list as its second argument.
* There is a new ``pkg_resources.add_activation_listener()`` API that lets
you register a callback for notifications about distributions added to
``sys.path`` (including the distributions already on it). This is
basically a hook for extensible applications and frameworks to be able to
search for plugin metadata in distributions added at runtime.
0.5a13
* Fixed a bug in resource extraction from nested packages in a zipped egg.
0.5a12
* Updated extraction/cache mechanism for zipped resources to avoid
inter-process and inter-thread races during extraction. The default cache
location can now be set via the ``PYTHON_EGGS_CACHE`` environment variable,
and the default Windows cache is now a ``Python-Eggs`` subdirectory of the
current user's "Application Data" directory, if the ``PYTHON_EGGS_CACHE``
variable isn't set.
0.5a10
* Fix a problem with ``pkg_resources`` being confused by non-existent eggs on
``sys.path`` (e.g. if a user deletes an egg without removing it from the
``easy-install.pth`` file).
* Fix a problem with "basket" support in ``pkg_resources``, where egg-finding
never actually went inside ``.egg`` files.
* Made ``pkg_resources`` import the module you request resources from, if it's
not already imported.
0.5a4
* ``pkg_resources.AvailableDistributions.resolve()`` and related methods now
accept an ``installer`` argument: a callable taking one argument, a
``Requirement`` instance. The callable must return a ``Distribution``
object, or ``None`` if no distribution is found. This feature is used by
EasyInstall to resolve dependencies by recursively invoking itself.
0.4a4
* Fix problems with ``resource_listdir()``, ``resource_isdir()`` and resource
directory extraction for zipped eggs.
0.4a3
* Fixed scripts not being able to see a ``__file__`` variable in ``__main__``
* Fixed a problem with ``resource_isdir()`` implementation that was introduced
in 0.4a2.
0.4a1
* Fixed a bug in requirements processing for exact versions (i.e. ``==`` and
``!=``) when only one condition was included.
* Added ``safe_name()`` and ``safe_version()`` APIs to clean up handling of
arbitrary distribution names and versions found on PyPI.
0.3a4
* ``pkg_resources`` now supports resource directories, not just the resources
in them. In particular, there are ``resource_listdir()`` and
``resource_isdir()`` APIs.
* ``pkg_resources`` now supports "egg baskets" -- .egg zipfiles which contain
multiple distributions in subdirectories whose names end with ``.egg``.
Having such a "basket" in a directory on ``sys.path`` is equivalent to
having the individual eggs in that directory, but the contained eggs can
be individually added (or not) to ``sys.path``. Currently, however, there
is no automated way to create baskets.
* Namespace package manipulation is now protected by the Python import lock.
0.3a1
* Initial release.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/python 2 sunset.rst 0000644 0001751 0000173 00000006722 14467657412 020110 0 ustar 00runner docker :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
`_). 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 environment, 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
`_
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.
././@PaxHeader 0000000 0000000 0000000 00000000034 00000000000 010212 x ustar 00 28 mtime=1692360483.4875476
setuptools-68.1.2/docs/references/ 0000755 0001751 0000173 00000000000 14467657443 016527 5 ustar 00runner docker ././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/references/keywords.rst 0000644 0001751 0000173 00000046401 14467657412 021131 0 ustar 00runner docker ========
Keywords
========
The following are keywords ``setuptools.setup()`` accepts.
They allow configuring the build process for a Python distribution or adding
metadata via a ``setup.py`` script placed at the root of your project.
All of them are optional; you do not have to supply them unless you need the
associated ``setuptools`` feature.
Metadata and configuration supplied via ``setup()`` is complementary to (and
may be overwritten by) the information present in ``setup.cfg`` and ``pyproject.toml``.
Some important metadata, such as ``name`` and ``version``, may assume
a default *degenerate* value if not specified.
Users are strongly encouraged to use a declarative config either via
:doc:`setup.cfg ` or :doc:`pyproject.toml
` and only rely on ``setup.py`` if they need to
tap into special behaviour that requires scripting (such as building C
extensions).
.. note::
When using declarative configs via ``pyproject.toml``
with ``setuptools<64.0.0``, users can still keep a very simple ``setup.py``
just to ensure editable installs are supported, for example::
from setuptools import setup
setup()
Versions of ``setuptools`` ``>=64.0.0`` do not require this extra minimal
``setup.py`` file.
.. _keyword/name:
``name``
A string specifying the name of the package.
.. _keyword/version:
``version``
A string specifying the version number of the package.
.. _keyword/description:
``description``
A string describing the package in a single line.
.. _keyword/long_description:
``long_description``
A string providing a longer description of the package.
.. _keyword/long_description_content_type:
``long_description_content_type``
A string specifying the content type is used for the ``long_description``
(e.g. ``text/markdown``)
.. _keyword/author:
``author``
A string specifying the author of the package.
.. _keyword/author_email:
``author_email``
A string specifying the email address of the package author.
.. _keyword/maintainer:
``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``.
.. _keyword/maintainer_email:
``maintainer_email``
A string specifying the email address of the current maintainer, if
different from the author.
.. _keyword/url:
``url``
A string specifying the URL for the package homepage.
.. _keyword/download_url:
``download_url``
A string specifying the URL to download the package.
.. _keyword/packages:
``packages``
A list of strings specifying the packages that setuptools will manipulate.
.. _keyword/py_modules:
``py_modules``
A list of strings specifying the modules that setuptools will manipulate.
.. _keyword/scripts:
``scripts``
A list of strings specifying the standalone script files to be built and
installed.
.. _keyword/ext_package:
``ext_package``
A string specifying the base package name for the extensions provided by
this package.
.. _keyword/ext_modules:
``ext_modules``
A list of instances of ``setuptools.Extension`` providing the list of
Python extensions to be built.
.. _keyword/classifiers:
``classifiers``
A list of strings describing the categories for the package.
.. _keyword/distclass:
``distclass``
A subclass of ``Distribution`` to use.
.. _keyword/script_name:
``script_name``
A string specifying the name of the setup.py script -- defaults to
``sys.argv[0]``
.. _keyword/script_args:
``script_args``
A list of strings defining the arguments to supply to the setup script.
.. _keyword/options:
``options``
A dictionary providing the default options for the setup script.
.. _keyword/license:
``license``
A string specifying the license of the package.
.. _keyword/license_file:
``license_file``
.. warning::
``license_file`` is deprecated. Use ``license_files`` instead.
.. _keyword/license_files:
``license_files``
A list of glob patterns for license related files that should be included.
If neither ``license_file`` nor ``license_files`` is specified, this option
defaults to ``LICEN[CS]E*``, ``COPYING*``, ``NOTICE*``, and ``AUTHORS*``.
.. _keyword/keywords:
``keywords``
A list of strings or a comma-separated string providing descriptive
meta-data. See: :ref:`Core Metadata Specifications`.
.. _keyword/platforms:
``platforms``
A list of strings or comma-separated string.
.. _keyword/cmdclass:
``cmdclass``
A dictionary providing a mapping of command names to ``Command``
subclasses.
.. _keyword/data_files:
``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.
.. _keyword/package_dir:
``package_dir``
A dictionary that maps package names (as they will be
imported by the end-users) into directory paths (that actually exist in the
project's source tree). This configuration has two main purposes:
1. To effectively "rename" paths when building your package.
For example, ``package_dir={"mypkg": "dir1/dir2/code_for_mypkg"}``
will instruct setuptools to copy the ``dir1/dir2/code_for_mypkg/...`` files
as ``mypkg/...`` when building the final :term:`wheel distribution `.
.. attention::
While it is *possible* to specify arbitrary mappings, developers are
**STRONGLY ADVISED AGAINST** that. They should try as much as possible
to keep the directory names and hierarchy identical to the way they will
appear in the final wheel, only deviating when absolutely necessary.
2. To indicate that the relevant code is entirely contained inside
a specific directory (instead of directly placed under the project's root).
In this case, a special key is required (the empty string, ``""``),
for example: ``package_dir={"": ""}``.
All the directories inside the container directory will be copied
directly into the final :term:`wheel distribution `, but the
container directory itself will not.
This practice is very common in the community to help separate the
package implementation from auxiliary files (e.g. CI configuration files),
and is referred to as :ref:`src-layout`, because the container
directory is commonly named ``src``.
All paths in ``package_dir`` must be relative to the project root directory
and use a forward slash (``/``) as path separator regardless of the
operating system.
.. tip::
When using :doc:`package discovery `
together with :doc:`setup.cfg ` or
:doc:`pyproject.toml `, it is very likely
that you don't need to specify a value for ``package_dir``. Please have
a look at the definitions of :ref:`src-layout` and :ref:`flat-layout` to
learn common practices on how to design a project's directory structure
and minimise the amount of configuration that is needed.
.. _keyword/requires:
``requires``
.. warning::
``requires`` is superseded by ``install_requires`` and should not be used
anymore.
.. _keyword/obsoletes:
``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.
.. _keyword/provides:
``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"``).
.. _keyword/include_package_data:
``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`.
.. _keyword/exclude_package_data:
``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`.
.. _keyword/package_data:
``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.)
.. _keyword/zip_safe:
``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.
.. _keyword/install_requires:
``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.
.. _keyword/entry_points:
``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 `.
.. _keyword/extras_require:
``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.
.. _keyword/python_requires:
``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.
.. _keyword/setup_requires:
``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 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``.)
.. _keyword/dependency_links:
``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 during install by tools that support them.
.. _keyword/namespace_packages:
``namespace_packages``
.. warning::
The ``namespace_packages`` implementation relies on ``pkg_resources``.
However, ``pkg_resources`` has some undesirable behaviours, and
Setuptools intends to obviate its usage in the future. Therefore,
``namespace_packages`` was deprecated in favor of native/implicit
namespaces (:pep:`420`). Check :doc:`the Python Packaging User Guide
` for more information.
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.
.. _keyword/test_suite:
``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.
.. warning::
.. deprecated:: 41.5.0
The test command will be removed in a future version of ``setuptools``,
alongside any test configuration parameter.
.. _keyword/tests_require:
``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.
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.
.. warning::
.. deprecated:: 41.5.0
The test command will be removed in a future version of ``setuptools``,
alongside any test configuration parameter.
.. _test_loader:
.. _keyword/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.
.. warning::
.. deprecated:: 41.5.0
The test command will be removed in a future version of ``setuptools``,
alongside any test configuration parameter.
.. _keyword/eager_resources:
``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`.
.. _keyword/project_urls:
``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.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/roadmap.rst 0000644 0001751 0000173 00000000241 14467657412 016554 0 ustar 00runner docker =======
Roadmap
=======
Setuptools maintains a series of `milestones
`_ to track
a roadmap of large-scale goals.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/setuptools.rst 0000644 0001751 0000173 00000015235 14467657412 017363 0 ustar 00runner docker ==================================================
Building and Distributing Packages with Setuptools
==================================================
``Setuptools`` is a collection of enhancements to the Python ``distutils``
that allow developers to more easily build and
distribute Python packages, especially ones that have dependencies on other
packages.
Packages built and distributed using ``setuptools`` look to the user like
ordinary Python packages based on the ``distutils``.
Feature Highlights:
* Create `Python Eggs `_ -
a single-file importable distribution format
* Enhanced support for accessing data files hosted in zipped packages.
* Automatically include all packages in your source tree, without listing them
individually in setup.py
* Automatically include all relevant files in your source distributions,
without needing to create a |MANIFEST.in|_ file, and without having to force
regeneration of the ``MANIFEST`` file when your source tree changes
[#manifest]_.
* Automatically generate wrapper scripts or Windows (console and GUI) .exe
files for any number of "main" functions in your project. (Note: this is not
a py2exe replacement; the .exe files rely on the local Python installation.)
* Transparent Cython support, so that your setup.py can list ``.pyx`` files and
still work even when the end-user doesn't have Cython installed (as long as
you include the Cython-generated C in your source distribution)
* Command aliases - create project-specific, per-user, or site-wide shortcut
names for commonly used commands and options
* Deploy your project in "development mode", such that it's available on
``sys.path``, yet can still be edited directly from its source checkout.
* Easily extend the distutils with new commands or ``setup()`` arguments, and
distribute/reuse your extensions for multiple projects, without copying code.
* Create extensible applications and frameworks that automatically discover
extensions, using simple "entry points" declared in a project's setup script.
* Full support for PEP 420 via ``find_namespace_packages()``, which is also backwards
compatible to the existing ``find_packages()`` for Python >= 3.3.
-----------------
Developer's Guide
-----------------
The developer's guide has been updated. See the :doc:`most recent version `.
TRANSITIONAL NOTE
~~~~~~~~~~~~~~~~~
Setuptools automatically calls ``declare_namespace()`` for you at runtime,
but future versions may *not*. This is because the automatic declaration
feature has some negative side effects, such as needing to import all namespace
packages during the initialization of the ``pkg_resources`` runtime, and also
the need for ``pkg_resources`` to be explicitly imported before any namespace
packages work at all. In some future releases, you'll be responsible
for including your own declaration lines, and the automatic declaration feature
will be dropped to get rid of the negative side effects.
During the remainder of the current development cycle, therefore, setuptools
will warn you about missing ``declare_namespace()`` calls in your
``__init__.py`` files, and you should correct these as soon as possible
before the compatibility support is removed.
Namespace packages without declaration lines will not work
correctly once a user has upgraded to a later version, so it's important that
you make this change now in order to avoid having your code break in the field.
Our apologies for the inconvenience, and thank you for your patience.
setup.cfg-only projects
=======================
.. versionadded:: 40.9.0
If ``setup.py`` is missing from the project directory when a :pep:`517`
build is invoked, ``setuptools`` emulates a dummy ``setup.py`` file containing
only a ``setuptools.setup()`` call.
.. note::
:pep:`517` doesn't support editable installs so this is currently
incompatible with ``pip install -e .``.
This means that you can have a Python project with all build configuration
specified in ``setup.cfg``, without a ``setup.py`` file, if you **can rely
on** your project always being built by a :pep:`517`/:pep:`518` compatible
frontend.
To use this feature:
* Specify build requirements and :pep:`517` build backend in
``pyproject.toml``.
For example:
.. code-block:: toml
[build-system]
requires = [
"setuptools >= 40.9.0",
]
build-backend = "setuptools.build_meta"
* Use a :pep:`517` compatible build frontend, such as ``pip >= 19`` or ``build``.
.. warning::
As :pep:`517` is new, support is not universal, and frontends that
do support it may still have bugs. For compatibility, you may want to
put a ``setup.py`` file containing only a ``setuptools.setup()``
invocation.
Configuration API
=================
Some automation tools may wish to access data from a configuration file.
``Setuptools`` exposes a ``read_configuration()`` function for
parsing ``metadata`` and ``options`` sections into a dictionary.
.. code-block:: python
from setuptools.config import read_configuration
conf_dict = read_configuration("/home/user/dev/package/setup.cfg")
By default, ``read_configuration()`` will read only the file provided
in the first argument. To include values from other configuration files
which could be in various places, set the ``find_others`` keyword argument
to ``True``.
If you have only a configuration file but not the whole package, you can still
try to get data out of it with the help of the ``ignore_option_errors`` keyword
argument. When it is set to ``True``, all options with errors possibly produced
by directives, such as ``attr:`` and others, will be silently ignored.
As a consequence, the resulting dictionary will include no such options.
Forum and Bug Tracker
=====================
Please use `GitHub Discussions`_ for questions and discussion about
setuptools, and the `setuptools bug tracker`_ ONLY for issues you have
confirmed via the forum are actual bugs, and which you have reduced to a minimal
set of steps to reproduce.
.. _GitHub Discussions: https://github.com/pypa/setuptools/discussions
.. _setuptools bug tracker: https://github.com/pypa/setuptools/
----
.. [#manifest] The default behaviour for ``setuptools`` will work well for pure
Python packages, or packages with simple C extensions (that don't require
any special C header). See :ref:`Controlling files in the distribution` and
:doc:`userguide/datafiles` for more information about complex scenarios, if
you want to include other types of files.
.. |MANIFEST.in| replace:: ``MANIFEST.in``
.. _MANIFEST.in: https://packaging.python.org/en/latest/guides/using-manifest-in/
././@PaxHeader 0000000 0000000 0000000 00000000033 00000000000 010211 x ustar 00 27 mtime=1692360483.491548
setuptools-68.1.2/docs/userguide/ 0000755 0001751 0000173 00000000000 14467657443 016402 5 ustar 00runner docker ././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/userguide/datafiles.rst 0000644 0001751 0000173 00000042546 14467657412 021077 0 ustar 00runner docker ====================
Data Files Support
====================
Old packaging installation methods in the Python ecosystem
have traditionally allowed installation of "data files", which
are placed in a platform-specific location. However, the most common use case
for data files distributed with a package is for use *by* the package, usually
by including the data files **inside the package directory**.
Setuptools focuses on this most common type of data files and offers three ways
of specifying which files should be included in your packages, as described in
the following sections.
include_package_data
====================
First, you can simply use the ``include_package_data`` keyword.
For example, if the package tree looks like this::
project_root_directory
├── setup.py # and/or setup.cfg, pyproject.toml
└── src
└── mypkg
├── __init__.py
├── data1.rst
├── data2.rst
├── data1.txt
└── data2.txt
and you supply this configuration:
.. tab:: setup.cfg
.. code-block:: ini
[options]
# ...
packages = find:
package_dir =
= src
include_package_data = True
[options.packages.find]
where = src
.. tab:: setup.py
.. code-block:: python
from setuptools import setup, find_packages
setup(
# ...,
packages=find_packages(where="src"),
package_dir={"": "src"},
include_package_data=True
)
.. tab:: pyproject.toml
.. code-block:: toml
[tool.setuptools]
# ...
# By default, include-package-data is true in pyproject.toml, so you do
# NOT have to specify this line.
include-package-data = true
[tool.setuptools.packages.find]
where = ["src"]
then all the ``.txt`` and ``.rst`` files will be automatically installed with
your package, provided:
1. These files are included via the |MANIFEST.in|_ file, like so::
include src/mypkg/*.txt
include src/mypkg/*.rst
2. OR, they are being tracked by a revision control system such as Git, Mercurial
or SVN, and you have configured an appropriate plugin such as
:pypi:`setuptools-scm` or :pypi:`setuptools-svn`.
(See the section below on :ref:`Adding Support for Revision
Control Systems` for information on how to write such plugins.)
package_data
============
By default, ``include_package_data`` considers **all** non ``.py`` files found inside
the package directory (``src/mypkg`` in this case) as data files, and includes those that
satisfy (at least) one of the above two conditions into the source distribution, and
consequently in the installation of your package.
If you want finer-grained control over what files are included, then you can also use
the ``package_data`` keyword.
For example, if the package tree looks like this::
project_root_directory
├── setup.py # and/or setup.cfg, pyproject.toml
└── src
└── mypkg
├── __init__.py
├── data1.rst
├── data2.rst
├── data1.txt
└── data2.txt
then you can use the following configuration to capture the ``.txt`` and ``.rst`` files as
data files:
.. tab:: setup.cfg
.. code-block:: ini
[options]
# ...
packages = find:
package_dir =
= src
[options.packages.find]
where = src
[options.package_data]
mypkg =
*.txt
*.rst
.. tab:: setup.py
.. code-block:: python
from setuptools import setup, find_packages
setup(
# ...,
packages=find_packages(where="src"),
package_dir={"": "src"},
package_data={"mypkg": ["*.txt", "*.rst"]}
)
.. tab:: pyproject.toml
.. code-block:: toml
[tool.setuptools.packages.find]
where = ["src"]
[tool.setuptools.package-data]
mypkg = ["*.txt", "*.rst"]
The ``package_data`` argument is a dictionary that maps from package names to
lists of glob patterns. Note that the data files specified using the ``package_data``
option neither require to be included within a |MANIFEST.in|_ file, nor
require to be added by a revision control system plugin.
.. note::
If your glob patterns use paths, you *must* use a forward slash (``/``) as
the path separator, even if you are on Windows. Setuptools automatically
converts slashes to appropriate platform-specific separators at build time.
.. note::
Glob patterns do not automatically match dotfiles (directory or file names
starting with a dot (``.``)). To include such files, you must explicitly start
the pattern with a dot, e.g. ``.*`` to match ``.gitignore``.
If you have multiple top-level packages and a common pattern of data files for all these
packages, for example::
project_root_directory
├── setup.py # and/or setup.cfg, pyproject.toml
└── src
├── mypkg1
│ ├── data1.rst
│ ├── data1.txt
│ └── __init__.py
└── mypkg2
├── data2.txt
└── __init__.py
Here, both packages ``mypkg1`` and ``mypkg2`` share a common pattern of having ``.txt``
data files. However, only ``mypkg1`` has ``.rst`` data files. In such a case, if you want to
use the ``package_data`` option, the following configuration will work:
.. tab:: setup.cfg
.. code-block:: ini
[options]
packages = find:
package_dir =
= src
[options.packages.find]
where = src
[options.package_data]
* =
*.txt
mypkg1 =
data1.rst
.. tab:: setup.py
.. code-block:: python
from setuptools import setup, find_packages
setup(
# ...,
packages=find_packages(where="src"),
package_dir={"": "src"},
package_data={"": ["*.txt"], "mypkg1": ["data1.rst"]},
)
.. tab:: pyproject.toml
.. code-block:: toml
[tool.setuptools.packages.find]
where = ["src"]
[tool.setuptools.package-data]
"*" = ["*.txt"]
mypkg1 = ["data1.rst"]
Notice that if you list patterns in ``package_data`` under the empty string ``""`` in
``setup.py``, and the asterisk ``*`` in ``setup.cfg`` and ``pyproject.toml``, these
patterns are used to find files in every package. For example, we use ``""`` or ``*``
to indicate that the ``.txt`` files from all packages should be captured as data files.
Also note how we can continue to specify patterns for individual packages, i.e.
we specify that ``data1.rst`` from ``mypkg1`` alone should be captured as well.
.. note::
When building an ``sdist``, the datafiles are also drawn from the
``package_name.egg-info/SOURCES.txt`` file, so make sure that this is removed if
the ``setup.py`` ``package_data`` list is updated before calling ``setup.py``.
exclude_package_data
====================
Sometimes, the ``include_package_data`` or ``package_data`` options alone
aren't sufficient to precisely define what files you want included. For example,
consider a scenario where you have ``include_package_data=True``, and you are using
a revision control system with an appropriate plugin.
Sometimes developers add directory-specific marker files (such as ``.gitignore``,
``.gitkeep``, ``.gitattributes``, or ``.hgignore``), these files are probably being
tracked by the revision control system, and therefore by default they will be
included when the package is installed.
Supposing you want to prevent these files from being included in the
installation (they are not relevant to Python or the package), then you could
use the ``exclude_package_data`` option:
.. tab:: setup.cfg
.. code-block:: ini
[options]
# ...
packages = find:
package_dir =
= src
include_package_data = True
[options.packages.find]
where = src
[options.exclude_package_data]
mypkg =
.gitattributes
.. tab:: setup.py
.. code-block:: python
from setuptools import setup, find_packages
setup(
# ...,
packages=find_packages(where="src"),
package_dir={"": "src"},
include_package_data=True,
exclude_package_data={"mypkg": [".gitattributes"]},
)
.. tab:: pyproject.toml
.. code-block:: toml
[tool.setuptools.packages.find]
where = ["src"]
[tool.setuptools.exclude-package-data]
mypkg = [".gitattributes"]
The ``exclude_package_data`` option is a dictionary mapping package names to
lists of wildcard patterns, just like the ``package_data`` option. And, just
as with that option, you can use the empty string key ``""`` in ``setup.py`` and the
asterisk ``*`` in ``setup.cfg`` and ``pyproject.toml`` to match all top-level packages.
Any files that match these patterns will be *excluded* from installation,
even if they were listed in ``package_data`` or were included as a result of using
``include_package_data``.
Subdirectory for Data Files
===========================
A common pattern is where some (or all) of the data files are placed under
a separate subdirectory. For example::
project_root_directory
├── setup.py # and/or setup.cfg, pyproject.toml
└── src
└── mypkg
├── data
│ ├── data1.rst
│ └── data2.rst
├── __init__.py
├── data1.txt
└── data2.txt
Here, the ``.rst`` files are placed under a ``data`` subdirectory inside ``mypkg``,
while the ``.txt`` files are directly under ``mypkg``.
In this case, the recommended approach is to treat ``data`` as a namespace package
(refer :pep:`420`). With ``package_data``,
the configuration might look like this:
.. tab:: setup.cfg
.. code-block:: ini
[options]
# ...
packages = find_namespace:
package_dir =
= src
[options.packages.find]
where = src
[options.package_data]
mypkg =
*.txt
mypkg.data =
*.rst
.. tab:: setup.py
.. code-block:: python
from setuptools import setup, find_namespace_packages
setup(
# ...,
packages=find_namespace_packages(where="src"),
package_dir={"": "src"},
package_data={
"mypkg": ["*.txt"],
"mypkg.data": ["*.rst"],
}
)
.. tab:: pyproject.toml
.. code-block:: toml
[tool.setuptools.packages.find]
# scanning for namespace packages is true by default in pyproject.toml, so
# you do NOT need to include the following line.
namespaces = true
where = ["src"]
[tool.setuptools.package-data]
mypkg = ["*.txt"]
"mypkg.data" = ["*.rst"]
In other words, we allow Setuptools to scan for namespace packages in the ``src`` directory,
which enables the ``data`` directory to be identified, and then, we separately specify data
files for the root package ``mypkg``, and the namespace package ``data`` under the package
``mypkg``.
With ``include_package_data`` the configuration is simpler: you simply need to enable
scanning of namespace packages in the ``src`` directory and the rest is handled by Setuptools.
.. tab:: setup.cfg
.. code-block:: ini
[options]
packages = find_namespace:
package_dir =
= src
include_package_data = True
[options.packages.find]
where = src
.. tab:: setup.py
.. code-block:: python
from setuptools import setup, find_namespace_packages
setup(
# ... ,
packages=find_namespace_packages(where="src"),
package_dir={"": "src"},
include_package_data=True,
)
.. tab:: pyproject.toml
.. code-block:: toml
[tool.setuptools]
# ...
# By default, include-package-data is true in pyproject.toml, so you do
# NOT have to specify this line.
include-package-data = true
[tool.setuptools.packages.find]
# scanning for namespace packages is true by default in pyproject.toml, so
# you need NOT include the following line.
namespaces = true
where = ["src"]
Summary
=======
In summary, the three options allow you to:
``include_package_data``
Accept all data files and directories matched by |MANIFEST.in|_ or added by
a :ref:`plugin `.
``package_data``
Specify additional patterns to match files that may or may
not be matched by |MANIFEST.in|_ or added by
a :ref:`plugin `.
``exclude_package_data``
Specify patterns for data files and directories that should *not* be
included when a package is installed, even if they would otherwise have
been included due to the use of the preceding options.
.. note::
Due to the way the build process works, a data file that you
include in your project and then stop including may be "orphaned" in your
project's build directories, requiring you to run ``setup.py clean --all`` to
fully remove them. This may also be important for your users and contributors
if they track intermediate revisions of your project using Subversion; be sure
to let them know when you make changes that remove files from inclusion so they
can run ``setup.py clean --all``.
.. _Accessing Data Files at Runtime:
Accessing Data Files at Runtime
===============================
Typically, existing programs manipulate a package's ``__file__`` attribute in
order to find the location of data files. For example, if you have a structure
like this::
project_root_directory
├── setup.py # and/or setup.cfg, pyproject.toml
└── src
└── mypkg
├── data
│ └── data1.txt
├── __init__.py
└── foo.py
Then, in ``mypkg/foo.py``, you may try something like this in order to access
``mypkg/data/data1.txt``:
.. code-block:: python
import os
data_path = os.path.join(os.path.dirname(__file__), 'data', 'data1.txt')
with open(data_path, 'r') as data_file:
...
However, this manipulation isn't compatible with :pep:`302`-based import hooks,
including importing from zip files and Python Eggs. It is strongly recommended that,
if you are using data files, you should use :mod:`importlib.resources` to access them.
In this case, you would do something like this:
.. code-block:: python
from importlib.resources import files
data_text = files('mypkg.data').joinpath('data1.txt').read_text()
:mod:`importlib.resources` was added to Python 3.7. However, the API illustrated in
this code (using ``files()``) was added only in Python 3.9, [#files_api]_ and support
for accessing data files via namespace packages was added only in Python 3.10 [#namespace_support]_
(the ``data`` subdirectory is a namespace package under the root package ``mypkg``).
Therefore, you may find this code to work only in Python 3.10 (and above). For other
versions of Python, you are recommended to use the :pypi:`importlib-resources` backport
which provides the latest version of this library. In this case, the only change that
has to be made to the above code is to replace ``importlib.resources`` with ``importlib_resources``, i.e.
.. code-block:: python
from importlib_resources import files
...
See :doc:`importlib-resources:using` for detailed instructions.
.. tip:: Files inside the package directory should be *read-only* to avoid a
series of common problems (e.g. when multiple users share a common Python
installation, when the package is loaded from a zip file, or when multiple
instances of a Python application run in parallel).
If your Python package needs to write to a file for shared data or configuration,
you can use standard platform/OS-specific system directories, such as
``~/.local/config/$appname`` or ``/usr/share/$appname/$version`` (Linux specific) [#system-dirs]_.
A common approach is to add a read-only template file to the package
directory that is then copied to the correct system directory if no
pre-existing file is found.
Non-Package Data Files
======================
Historically, ``setuptools`` by way of ``easy_install`` would encapsulate data
files from the distribution into the egg (see `the old docs
`_). As eggs are deprecated and pip-based installs
fall back to the platform-specific location for installing data files, there is
no supported facility to reliably retrieve these resources.
Instead, the PyPA recommends that any data files you wish to be accessible at
run time be included **inside the package**.
----
.. [#system-dirs] These locations can be discovered with the help of
third-party libraries such as :pypi:`platformdirs`.
.. [#files_api] Reference: https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy
.. [#namespace_support] Reference: https://github.com/python/importlib_resources/pull/196#issuecomment-734520374
.. |MANIFEST.in| replace:: ``MANIFEST.in``
.. _MANIFEST.in: https://packaging.python.org/en/latest/guides/using-manifest-in/
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/userguide/declarative_config.rst 0000644 0001751 0000173 00000031405 14467657412 022743 0 ustar 00runner docker .. _declarative config:
------------------------------------------------
Configuring setuptools using ``setup.cfg`` files
------------------------------------------------
.. note:: New in 30.3.0 (8 Dec 2016).
.. important::
If compatibility with legacy builds (i.e. those not using the :pep:`517`
build API) is desired, a ``setup.py`` file containing a ``setup()`` function
call is still required even if your configuration resides in ``setup.cfg``.
``Setuptools`` allows using configuration files (usually :file:`setup.cfg`)
to define a package’s metadata and other options that are normally supplied
to the ``setup()`` function (declarative config).
This approach not only allows automation scenarios but also reduces
boilerplate code in some cases.
.. _example-setup-config:
.. code-block:: ini
[metadata]
name = my_package
version = attr: my_package.VERSION
author = Josiah Carberry
author_email = josiah_carberry@brown.edu
description = My package description
long_description = file: README.rst, CHANGELOG.rst, LICENSE.rst
keywords = one, two
license = BSD-3-Clause
classifiers =
Framework :: Django
Programming Language :: Python :: 3
[options]
zip_safe = False
include_package_data = True
packages = find:
python_requires = >=3.7
install_requires =
requests
importlib-metadata; python_version<"3.8"
[options.package_data]
* = *.txt, *.rst
hello = *.msg
[options.entry_points]
console_scripts =
executable-name = my_package.module:function
[options.extras_require]
pdf = ReportLab>=1.2; RXP
rest = docutils>=0.3; pack ==1.1, ==1.3
[options.packages.find]
exclude =
examples*
tools*
docs*
my_package.tests*
Metadata and options are set in the config sections of the same name.
* Keys are the same as the :doc:`keyword arguments ` one
provides to the ``setup()`` function.
* Complex values can be written comma-separated or placed one per line
in *dangling* config values. The following are equivalent:
.. code-block:: ini
[metadata]
keywords = one, two
[metadata]
keywords =
one
two
* In some cases, complex values can be provided in dedicated subsections for
clarity.
* Some keys allow ``file:``, ``attr:``, ``find:``, and ``find_namespace:`` directives in
order to cover common usecases.
* Unknown keys are ignored.
Using a ``src/`` layout
=======================
One commonly used configuration has all the Python source code in a
subdirectory (often called the ``src/`` layout), like this::
├── src
│ └── mypackage
│ ├── __init__.py
│ └── mod1.py
├── setup.py
└── setup.cfg
You can set up your ``setup.cfg`` to automatically find all your packages in
the subdirectory, using :ref:`package_dir `, like this:
.. code-block:: ini
# This example contains just the necessary options for a src-layout, set up
# the rest of the file as described above.
[options]
package_dir=
=src
packages=find:
[options.packages.find]
where=src
In this example, the value for the :ref:`package_dir `
configuration (i.e. ``=src``) is parsed as ``{"": "src"}``.
The ``""`` key has a special meaning in this context, and indicates that all the
packages are contained inside the given directory.
Also note that the value for ``[options.packages.find] where`` matches the
value associated with ``""`` in the ``package_dir`` dictionary.
..
TODO: Add the following tip once the auto-discovery is no longer experimental:
Starting in version 61, ``setuptools`` can automatically infer the
configurations for both ``packages`` and ``package_dir`` for projects using
a ``src/`` layout (as long as no value is specified for ``py_modules``).
Please see :doc:`package discovery ` for more
details.
Specifying values
=================
Some values are treated as simple strings, some allow more logic.
Type names used below:
* ``str`` - simple string
* ``list-comma`` - dangling list or string of comma-separated values
* ``list-semi`` - dangling list or string of semicolon-separated values
* ``bool`` - ``True`` is 1, yes, true
* ``dict`` - list-comma where each entry corresponds to a key/value pair,
with keys separated from values by ``=``.
If an entry starts with ``=``, the key is assumed to be an empty string
(e.g. ``=src`` is parsed as ``{"": "src"}``).
* ``section`` - values are read from a dedicated (sub)section
Special directives:
* ``attr:`` - Value is read from a module attribute. ``attr:`` supports
callables and iterables; unsupported types are cast using ``str()``.
In order to support the common case of a literal value assigned to a variable
in a module containing (directly or indirectly) third-party imports,
``attr:`` first tries to read the value from the module by examining the
module's AST. If that fails, ``attr:`` falls back to importing the module.
* ``file:`` - Value is read from a list of files and then concatenated
.. important::
The ``file:`` directive is sandboxed and won't reach anything outside the
project directory (i.e. the directory containing ``setup.cfg``/``pyproject.toml``).
.. note::
If you are using an old version of ``setuptools``, you might need to ensure
that all files referenced by the ``file:`` directive are included in the ``sdist``
(you can do that via ``MANIFEST.in`` or using plugins such as ``setuptools-scm``,
please have a look on :doc:`/userguide/miscellaneous` for more information).
.. versionchanged:: 66.1.0
Newer versions of ``setuptools`` will automatically add these files to the ``sdist``.
Metadata
--------
.. attention::
The aliases given below are supported for compatibility reasons,
but their use is not advised.
============================== ================= ================= =============== ==========
Key Aliases Type Minimum Version Notes
============================== ================= ================= =============== ==========
name str
version attr:, file:, str 39.2.0 [#meta-1]_
url home-page str
download_url download-url str
project_urls dict 38.3.0
author str
author_email author-email str
maintainer str
maintainer_email maintainer-email str
classifiers classifier file:, list-comma
license str
license_files license_file list-comma 42.0.0
description summary file:, str
long_description long-description file:, str
long_description_content_type str 38.6.0
keywords list-comma
platforms platform list-comma
provides list-comma
requires list-comma
obsoletes list-comma
============================== ================= ================= =============== ==========
**Notes**:
.. [#meta-1] The ``version`` file attribute has only been supported since 39.2.0.
A version loaded using the ``file:`` directive must comply with PEP 440.
It is easy to accidentally put something other than a valid version
string in such a file, so validation is stricter in this case.
Options
-------
======================= =================================== =============== ====================
Key Type Minimum Version Notes
======================= =================================== =============== ====================
zip_safe bool
setup_requires list-semi 36.7.0
install_requires file:, list-semi **BETA** [#opt-2]_, [#opt-6]_
extras_require file:, section **BETA** [#opt-2]_, [#opt-6]_
python_requires str 34.4.0
entry_points file:, section 51.0.0
scripts list-comma
eager_resources list-comma
dependency_links list-comma
tests_require list-semi
include_package_data bool
packages find:, find_namespace:, list-comma [#opt-3]_
package_dir dict
package_data section [#opt-1]_
exclude_package_data section
namespace_packages list-comma [#opt-5]_
py_modules list-comma 34.4.0
data_files section 40.6.0 [#opt-4]_
======================= =================================== =============== ====================
**Notes**:
.. [#opt-1] In the ``package_data`` section, a key named with a single asterisk
(``*``) refers to all packages, in lieu of the empty string used in ``setup.py``.
.. [#opt-2] In ``install_requires`` and ``extras_require``, values are parsed as ``list-semi``.
This implies that in order to include markers, each requirement **must** be *dangling*
in a new line:
.. code-block:: ini
[options]
install_requires =
importlib-metadata; python_version<"3.8"
[options.extras_require]
all =
importlib-metadata; python_version < "3.8"
.. [#opt-3] The ``find:`` and ``find_namespace:`` directive can be further configured
in a dedicated subsection ``options.packages.find``. This subsection accepts the
same keys as the ``setuptools.find_packages`` and the
``setuptools.find_namespace_packages`` function:
``where``, ``include``, and ``exclude``.
The ``find_namespace:`` directive is supported since Python >=3.3.
.. [#opt-4] ``data_files`` is deprecated and should be avoided.
Please check :doc:`/userguide/datafiles` for more information.
.. [#opt-5] ``namespace_packages`` is deprecated in favour of native/implicit
namespaces (:pep:`420`). Check :doc:`the Python Packaging User Guide
` for more information.
.. [#opt-6] ``file:`` directives for reading requirements are supported since version 62.6.
The format for the file resembles a ``requirements.txt`` file,
however please keep in mind that all non-comment lines must conform with :pep:`508`
(``pip``-specify syntaxes, e.g. ``-c/-r/-e`` flags, are not supported).
Library developers should avoid tightly pinning their dependencies to a specific
version (e.g. via a "locked" requirements file).
Compatibility with other tools
==============================
Historically, several tools explored declarative package configuration
in parallel. And several of them chose to place the packaging
configuration within the project's :file:`setup.cfg` file.
One of the first was ``distutils2``, which development has stopped in
2013. Other include ``pbr`` which is still under active development or
``d2to1``, which was a plug-in that backports declarative configuration
to ``distutils``, but has had no release since Oct. 2015.
As a way to harmonize packaging tools, ``setuptools``, having held the
position of *de facto* standard, has gradually integrated those
features as part of its core features.
Still this has lead to some confusion and feature incompatibilities:
- some tools support features others don't;
- some have similar features but the declarative syntax differs;
The table below tries to summarize the differences. But, please, refer
to each tool documentation for up-to-date information.
=========================== ========== ========== ===== ===
feature setuptools distutils2 d2to1 pbr
=========================== ========== ========== ===== ===
[metadata] description-file S Y Y Y
[files] S Y Y Y
entry_points Y Y Y S
[backwards_compat] N Y Y Y
=========================== ========== ========== ===== ===
Y: supported, N: unsupported, S: syntax differs (see
:ref:`above example`).
Also note that some features were only recently added to ``setuptools``.
Please refer to the previous sections to find out when.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/userguide/dependency_management.rst 0000644 0001751 0000173 00000026511 14467657412 023447 0 ustar 00runner docker =====================================
Dependencies Management in Setuptools
=====================================
There are three types of dependency styles offered by setuptools:
1) build system requirement, 2) required dependency and 3) optional
dependency.
Each dependency, regardless of type, needs to be specified according to :pep:`508`
and :pep:`440`.
This allows adding version :pep:`range restrictions <440#version-specifiers>`
and :ref:`environment markers `.
.. _build-requires:
Build system requirement
========================
After organizing all the scripts and files and getting ready for packaging,
there needs to be a way to specify what programs and libraries are actually needed
do the packaging (in our case, ``setuptools`` of course).
This needs to be specified in your ``pyproject.toml`` file
(if you have forgot what this is, go to :doc:`/userguide/quickstart` or :doc:`/build_meta`):
.. code-block:: toml
[build-system]
requires = ["setuptools"]
#...
Please note that you should also include here any other ``setuptools`` plugin
(e.g., :pypi:`setuptools-scm`, :pypi:`setuptools-golang`, :pypi:`setuptools-rust`)
or build-time dependency (e.g., :pypi:`Cython`, :pypi:`cppy`, :pypi:`pybind11`).
.. note::
In previous versions of ``setuptools``,
this used to be accomplished with the ``setup_requires`` keyword but is
now considered deprecated in favor of the :pep:`517` style described above.
To peek into how this legacy keyword is used, consult our :doc:`guide on
deprecated practice (WIP) `.
.. _Declaring Dependencies:
Declaring required dependency
=============================
This is where a package declares its core dependencies, without which it won't
be able to run. ``setuptools`` supports automatically downloading and installing
these dependencies when the package is installed. Although there is more
finesse to it, let's start with a simple example.
.. tab:: pyproject.toml
.. code-block:: toml
[project]
# ...
dependencies = [
"docutils",
"BazSpam == 1.1",
]
# ...
.. tab:: setup.cfg
.. code-block:: ini
[options]
#...
install_requires =
docutils
BazSpam ==1.1
.. tab:: setup.py
.. code-block:: python
setup(
...,
install_requires=[
'docutils',
'BazSpam ==1.1',
],
)
When your project is installed (e.g., using :pypi:`pip`), all of the dependencies not
already installed will be located (via `PyPI`_), downloaded, built (if necessary),
and installed and 2) Any scripts in your project will be installed with wrappers
that verify the availability of the specified dependencies at runtime.
.. _environment-markers:
Platform specific dependencies
------------------------------
Setuptools offers the capability to evaluate certain conditions before blindly
installing everything listed in ``install_requires``. This is great for platform
specific dependencies. For example, the ``enum`` package was added in Python
3.4, therefore, package that depends on it can elect to install it only when
the Python version is older than 3.4. To accomplish this
.. tab:: pyproject.toml
.. code-block:: toml
[project]
# ...
dependencies = [
"enum34; python_version<'3.4'",
]
# ...
.. tab:: setup.cfg
.. code-block:: ini
[options]
#...
install_requires =
enum34;python_version<'3.4'
.. tab:: setup.py
.. code-block:: python
setup(
...,
install_requires=[
"enum34;python_version<'3.4'",
],
)
Similarly, if you also wish to declare ``pywin32`` with a minimal version of 1.0
and only install it if the user is using a Windows operating system:
.. tab:: pyproject.toml
.. code-block:: toml
[project]
# ...
dependencies = [
"enum34; python_version<'3.4'",
"pywin32 >= 1.0; platform_system=='Windows'",
]
# ...
.. tab:: setup.cfg
.. code-block:: ini
[options]
#...
install_requires =
enum34;python_version<'3.4'
pywin32 >= 1.0;platform_system=='Windows'
.. tab:: setup.py
.. code-block:: python
setup(
...,
install_requires=[
"enum34;python_version<'3.4'",
"pywin32 >= 1.0;platform_system=='Windows'",
],
)
The environmental markers that may be used for testing platform types are
detailed in :pep:`508`.
.. seealso::
Alternatively, a :ref:`backend wrapper ` can be used for
specific use cases where environment markers aren't sufficient.
Direct URL dependencies
-----------------------
.. attention::
`PyPI`_ and other standards-conformant package indices **do not** accept
packages that declare dependencies using direct URLs. ``pip`` will accept them
when installing packages from the local filesystem or from another URL,
however.
Dependencies that are not available on a package index but can be downloaded
elsewhere in the form of a source repository or archive may be specified
using a variant of :pep:`PEP 440's direct references <440#direct-references>`:
.. tab:: pyproject.toml
.. code-block:: toml
[project]
# ...
dependencies = [
"Package-A @ git+https://example.net/package-a.git@main",
"Package-B @ https://example.net/archives/package-b.whl",
]
.. tab:: setup.cfg
.. code-block:: ini
[options]
#...
install_requires =
Package-A @ git+https://example.net/package-a.git@main
Package-B @ https://example.net/archives/package-b.whl
.. tab:: setup.py
.. code-block:: python
setup(
install_requires=[
"Package-A @ git+https://example.net/package-a.git@main",
"Package-B @ https://example.net/archives/package-b.whl",
],
...,
)
For source repository URLs, a list of supported protocols and VCS-specific
features such as selecting certain branches or tags can be found in pip's
documentation on `VCS support `_.
Supported formats for archive URLs are sdists and wheels.
Optional dependencies
=====================
Setuptools allows you to declare dependencies that are not installed by default.
This effectively means that you can create a "variant" of your package with a
set of extra functionalities.
For example, let's consider a ``Package-A`` that offers
optional PDF support and requires two other dependencies for it to work:
.. tab:: pyproject.toml
.. code-block:: toml
[project]
name = "Package-A"
# ...
[project.optional-dependencies]
PDF = ["ReportLab>=1.2", "RXP"]
.. tab:: setup.cfg
.. code-block:: ini
[metadata]
name = Package-A
[options.extras_require]
PDF =
ReportLab>=1.2
RXP
.. tab:: setup.py
.. code-block:: python
setup(
name="Package-A",
...,
extras_require={
"PDF": ["ReportLab>=1.2", "RXP"],
},
)
.. sidebar::
.. tip::
It is also convenient to declare optional requirements for
ancillary tasks such as running tests and or building docs.
The name ``PDF`` is an arbitrary :pep:`identifier <685>` of such a list of dependencies, to
which other components can refer and have them installed.
A use case for this approach is that other package can use this "extra" for their
own dependencies. For example, if ``Package-B`` needs ``Package-A`` with PDF support
installed, it might declare the dependency like this:
.. tab:: pyproject.toml
.. code-block:: toml
[project]
name = "Package-B"
# ...
dependencies = [
"Package-A[PDF]"
]
.. tab:: setup.cfg
.. code-block:: ini
[metadata]
name = Package-B
#...
[options]
#...
install_requires =
Package-A[PDF]
.. tab:: setup.py
.. code-block:: python
setup(
name="Package-B",
install_requires=["Package-A[PDF]"],
...,
)
This will cause ``ReportLab`` to be installed along with ``Package-A``, if ``Package-B`` is
installed -- even if ``Package-A`` was already installed. In this way, a project
can encapsulate groups of optional "downstream dependencies" under a feature
name, so that packages that depend on it don't have to know what the downstream
dependencies are. If a later version of ``Package-A`` builds in PDF support and
no longer needs ``ReportLab``, or if it ends up needing other dependencies besides
``ReportLab`` in order to provide PDF support, ``Package-B``'s setup information does
not need to change, but the right packages will still be installed if needed.
.. tip::
Best practice: if a project ends up no longer needing any other packages to
support a feature, it should keep an empty requirements list for that feature
in its ``extras_require`` argument, so that packages depending on that feature
don't break (due to an invalid feature name).
.. warning::
Historically ``setuptools`` also used to support extra dependencies in console
scripts, for example:
.. tab:: setup.cfg
.. code-block:: ini
[metadata]
name = Package-A
#...
[options]
#...
entry_points=
[console_scripts]
rst2pdf = project_a.tools.pdfgen [PDF]
rst2html = project_a.tools.htmlgen
.. tab:: setup.py
.. code-block:: python
setup(
name="Package-A",
...,
entry_points={
"console_scripts": [
"rst2pdf = project_a.tools.pdfgen [PDF]",
"rst2html = project_a.tools.htmlgen",
],
},
)
This syntax indicates that the entry point (in this case a console script)
is only valid when the PDF extra is installed. It is up to the installer
to determine how to handle the situation where PDF was not indicated
(e.g., omit the console script, provide a warning when attempting to load
the entry point, assume the extras are present and let the implementation
fail later).
**However**, ``pip`` and other tools might not support this use case for extra
dependencies, therefore this practice is considered **deprecated**.
See :doc:`PyPUG:specifications/entry-points`.
Python requirement
==================
In some cases, you might need to specify the minimum required python version.
This can be configured as shown in the example below.
.. tab:: pyproject.toml
.. code-block:: toml
[project]
name = "Package-B"
requires-python = ">=3.6"
# ...
.. tab:: setup.cfg
.. code-block:: ini
[metadata]
name = Package-B
#...
[options]
#...
python_requires = >=3.6
.. tab:: setup.py
.. code-block:: python
setup(
name="Package-B",
python_requires=">=3.6",
...,
)
.. _PyPI: https://pypi.org
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/userguide/development_mode.rst 0000644 0001751 0000173 00000027764 14467657412 022476 0 ustar 00runner docker Development Mode (a.k.a. "Editable Installs")
=============================================
When creating a Python project, developers usually want to implement and test
changes iteratively, before cutting a release and preparing a distribution archive.
In normal circumstances this can be quite cumbersome and require the developers
to manipulate the ``PYTHONPATH`` environment variable or to continuously re-build
and re-install the project.
To facilitate iterative exploration and experimentation, setuptools allows
users to instruct the Python interpreter and its import machinery to load the
code under development directly from the project folder without having to
copy the files to a different location in the disk.
This means that changes in the Python source code can immediately take place
without requiring a new installation.
You can enter this "development mode" by performing an :doc:`editable installation
` inside of a :term:`virtual environment`,
using :doc:`pip's ` ``-e/--editable`` flag, as shown below:
.. code-block:: bash
$ cd your-python-project
$ python -m venv .venv
# Activate your environment with:
# `source .venv/bin/activate` on Unix/macOS
# or `.venv\Scripts\activate` on Windows
$ pip install --editable .
# Now you have access to your package
# as if it was installed in .venv
$ python -c "import your_python_project"
An "editable installation" works very similarly to a regular install with
``pip install .``, except that it only installs your package dependencies,
metadata and wrappers for :ref:`console and GUI scripts `.
Under the hood, setuptools will try to create a special :mod:`.pth file `
in the target directory (usually ``site-packages``) that extends the
``PYTHONPATH`` or install a custom :doc:`import hook `.
When you're done with a given development task, you can simply uninstall your
package (as you would normally do with ``pip uninstall ``).
Please note that, by default an editable install will expose at least all the
files that would be available in a regular installation. However, depending on
the file and directory organization in your project, it might also expose
as a side effect files that would not be normally available.
This is allowed so you can iteratively create new Python modules.
Please have a look on the following section if you are looking for a different behaviour.
.. admonition:: Virtual Environments
You can think about virtual environments as "isolated Python runtime deployments"
that allow users to install different sets of libraries and tools without
messing with the global behaviour of the system.
They are a safe way of testing new projects and can be created easily
with the :mod:`venv` module from the standard library.
Please note however that depending on your operating system or distribution,
``venv`` might not come installed by default with Python. For those cases,
you might need to use the OS package manager to install it.
For example, in Debian/Ubuntu-based systems you can obtain it via:
.. code-block:: bash
sudo apt install python3-venv
Alternatively, you can also try installing :pypi:`virtualenv`.
More information is available on the Python Packaging User Guide on
:doc:`PyPUG:guides/installing-using-pip-and-virtual-environments`.
.. note::
.. versionchanged:: v64.0.0
Editable installation hooks implemented according to :pep:`660`.
Support for :pep:`namespace packages <420>` is still **EXPERIMENTAL**.
"Strict" editable installs
--------------------------
When thinking about editable installations, users might have the following
expectations:
1. It should allow developers to add new files (or split/rename existing ones)
and have them automatically exposed.
2. It should behave as close as possible to a regular installation and help
users to detect problems (e.g. new files not being included in the distribution).
Unfortunately these expectations are in conflict with each other.
To solve this problem ``setuptools`` allows developers to choose a more
*"strict"* mode for the editable installation. This can be done by passing
a special *configuration setting* via :pypi:`pip`, as indicated below:
.. code-block:: bash
pip install -e . --config-settings editable_mode=strict
In this mode, new files **won't** be exposed and the editable installs will
try to mimic as much as possible the behavior of a regular install.
Under the hood, ``setuptools`` will create a tree of file links in an auxiliary
directory (``$your_project_dir/build``) and add it to ``PYTHONPATH`` via a
:mod:`.pth file `. (Please be careful to not delete this repository
by mistake otherwise your files may stop being accessible).
.. warning::
Strict editable installs require auxiliary files to be placed in a
``build/__editable__.*`` directory (relative to your project root).
Please be careful to not remove this directory while testing your project,
otherwise your editable installation may be compromised.
You can remove the ``build/__editable__.*`` directory after uninstalling.
.. note::
.. versionadded:: v64.0.0
Added new *strict* mode for editable installations.
The exact details of how this mode is implemented may vary.
Limitations
-----------
- The *editable* term is used to refer only to Python modules
inside the package directories. Non-Python files, external (data) files,
executable script files, binary extensions, headers and metadata may be
exposed as a *snapshot* of the version they were at the moment of the
installation.
- Adding new dependencies, entry-points or changing your project's metadata
require a fresh "editable" re-installation.
- Console scripts and GUI scripts **MUST** be specified via :doc:`entry-points
` to work properly.
- *Strict* editable installs require the file system to support
either :wiki:`symbolic ` or :wiki:`hard links `.
This installation mode might also generate auxiliary files under the project directory.
- There is *no guarantee* that the editable installation will be performed
using a specific technique. Depending on each project, ``setuptools`` may
select a different approach to ensure the package is importable at runtime.
- There is *no guarantee* that files outside the top-level package directory
will be accessible after an editable install.
- There is *no guarantee* that attributes like ``__path__`` or ``__file__``
will correspond to the exact location of the original files (e.g.,
``setuptools`` might employ file links to perform the editable installation).
Users are encouraged to use tools like :mod:`importlib.resources` or
:mod:`importlib.metadata` when trying to access package files directly.
- Editable installations may not work with
:doc:`namespaces created with pkgutil or pkg_resources
`.
Please use :pep:`420`-style implicit namespaces [#namespaces]_.
- Support for :pep:`420`-style implicit namespace packages for
projects structured using :ref:`flat-layout` is still **experimental**.
If you experience problems, you can try converting your package structure
to the :ref:`src-layout`.
- File system entries in the current working directory
whose names coincidentally match installed packages
may take precedence in :doc:`Python's import system `.
Users are encouraged to avoid such scenarios [#cwd]_.
- Setuptools will try to give the right precedence to modules in an editable install.
However this is not always an easy task. If you have a particular order in
``sys.path`` or some specific import precedence that needs to be respected,
the editable installation as supported by Setuptools might not be able to
fulfil this requirement, and therefore it might not be the right tool for your use case.
.. attention::
Editable installs are **not a perfect replacement for regular installs**
in a test environment. When in doubt, please test your projects as
installed via a regular wheel. There are tools in the Python ecosystem,
like :pypi:`tox` or :pypi:`nox`, that can help you with that
(when used with appropriate configuration).
Legacy Behavior
---------------
If your project is not compatible with the new "editable installs" or you wish
to replicate the legacy behavior, for the time being you can also perform the
installation in the ``compat`` mode:
.. code-block:: bash
pip install -e . --config-settings editable_mode=compat
This installation mode will try to emulate how ``python setup.py develop``
works (still within the context of :pep:`660`).
.. warning::
The ``compat`` mode is *transitional* and will be removed in
future versions of ``setuptools``, it exists only to help during the
migration period.
Also note that support for this mode is limited:
it is safe to assume that the ``compat`` mode is offered "as is", and
improvements are unlikely to be implemented.
Users are encouraged to try out the new editable installation techniques
and make the necessary adaptations.
.. note::
Newer versions of ``pip`` no longer run the fallback command
``python setup.py develop`` when the ``pyproject.toml`` file is present.
This means that setting the environment variable
``SETUPTOOLS_ENABLE_FEATURES="legacy-editable"``
will have no effect when installing a package with ``pip``.
How editable installations work
-------------------------------
*Advanced topic*
There are many techniques that can be used to expose packages under development
in such a way that they are available as if they were installed.
Depending on the project file structure and the selected mode, ``setuptools``
will choose one of these approaches for the editable installation [#criteria]_.
A non-exhaustive list of implementation mechanisms is presented below.
More information is available on the text of :pep:`PEP 660 <660#what-to-put-in-the-wheel>`.
- A static ``.pth`` file [#static_pth]_ can be added to one of the directories
listed in :func:`site.getsitepackages` or :func:`site.getusersitepackages` to
extend :obj:`sys.path`.
- A directory containing a *farm of file links* that mimic the
project structure and point to the original files can be employed.
This directory can then be added to :obj:`sys.path` using a static ``.pth`` file.
- A dynamic ``.pth`` file [#dynamic_pth]_ can also be used to install an
"import :term:`finder`" (:obj:`~importlib.abc.MetaPathFinder` or
:obj:`~importlib.abc.PathEntryFinder`) that will hook into Python's
:doc:`import system ` machinery.
.. attention::
``Setuptools`` offers **no guarantee** of which technique will be used to
perform an editable installation. This will vary from project to project
and may change depending on the specific version of ``setuptools`` being
used.
----
.. rubric:: Notes
.. [#namespaces]
You *may* be able to use *strict* editable installations with namespace
packages created with ``pkgutil`` or ``pkg_namespaces``, however this is not
officially supported.
.. [#cwd]
Techniques like the :ref:`src-layout` or tooling-specific options like
`tox's changedir `_
can be used to prevent such kinds of situations (checkout `this blog post
`_ for more
insights).
.. [#criteria]
``setuptools`` strives to find a balance between allowing the user to see
the effects of project files being edited while still trying to keep the
editable installation as similar as possible to a regular installation.
.. [#static_pth]
i.e., a ``.pth`` file where each line correspond to a path that should be
added to :obj:`sys.path`. See :mod:`Site-specific configuration hook `.
.. [#dynamic_pth]
i.e., a ``.pth`` file that starts where each line starts with an ``import``
statement and executes arbitrary Python code. See :mod:`Site-specific
configuration hook `.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/userguide/distribution.rst 0000644 0001751 0000173 00000024112 14467657412 021647 0 ustar 00runner docker .. _Specifying Your Project's Version:
Specifying Your Project's Version
=================================
Setuptools can work well with most versioning schemes. Over the years,
setuptools has tried to closely follow the :pep:`440` scheme, but it
also supports legacy versions. There are, however, a
few special things to watch out for, in order to ensure that setuptools and
other tools can always tell what version of your package is newer than another
version. Knowing these things will also help you correctly specify what
versions of other projects your project depends on.
A version consists of an alternating series of release numbers and
`pre-release `_
or `post-release `_ tags. A
release number is a series of digits punctuated by
dots, such as ``2.4`` or ``0.5``. Each series of digits is treated
numerically, so releases ``2.1`` and ``2.1.0`` are different ways to spell the
same release number, denoting the first subrelease of release 2. But ``2.10``
is the *tenth* subrelease of release 2, and so is a different and newer release
from ``2.1`` or ``2.1.0``. Leading zeros within a series of digits are also
ignored, so ``2.01`` is the same as ``2.1``, and different from ``2.0.1``.
Following a release number, you can have either a pre-release or post-release
tag. Pre-release tags make a version be considered *older* than the version
they are appended to. So, revision ``2.4`` is *newer* than release candidate
``2.4rc1``, which in turn is newer than beta release ``2.4b1`` or
alpha release ``2.4a1``. Postrelease tags make
a version be considered *newer* than the version they are appended to. So,
revisions like ``2.4.post1`` are newer than ``2.4``, but *older*
than ``2.4.1`` (which has a higher release number).
In the case of legacy versions (for example, ``2.4pl1``), they are considered
older than non-legacy versions. Taking that in count, a revision ``2.4pl1``
is *older* than ``2.4``. Note that ``2.4pl1`` is not :pep:`440`-compliant.
A pre-release tag is a series of letters that are alphabetically before
"final". Some examples of prerelease tags would include ``alpha``, ``beta``,
``a``, ``c``, ``dev``, and so on. You do not have to place a dot or dash
before the prerelease tag if it's immediately after a number, but it's okay to
do so if you prefer. Thus, ``2.4c1`` and ``2.4.c1`` and ``2.4-c1`` all
represent release candidate 1 of version ``2.4``, and are treated as identical
by setuptools. Note that only ``a``, ``b``, and ``rc`` are :pep:`440`-compliant
pre-release tags.
In addition, there are three special prerelease tags that are treated as if
they were ``rc``: ``c``, ``pre``, and ``preview``. So, version
``2.4c1``, ``2.4pre1`` and ``2.4preview1`` are all the exact same version as
``2.4rc1``, and are treated as identical by setuptools.
A post-release tag is the string ``.post``, followed by a non-negative integer
value. Post-release tags are generally used to separate patch numbers, port
numbers, build numbers, revision numbers, or date stamps from the release
number. For example, the version ``2.4.post1263`` might denote Subversion
revision 1263 of a post-release patch of version ``2.4``. Or you might use
``2.4.post20051127`` to denote a date-stamped post-release. Legacy post-release
tags could be either a series of letters that are alphabetically greater than or
equal to "final", or a dash (``-``) - for example ``2.4-r1263`` or
``2.4-20051127``.
Notice that after each legacy pre or post-release tag, you are free to place
another release number, followed again by more pre- or post-release tags. For
example, ``0.6a9.dev41475`` could denote Subversion revision 41475 of the
in-development version of the ninth alpha of release 0.6. Notice that ``dev``
is a pre-release tag, so this version is a *lower* version number than
``0.6a9``, which would be the actual ninth alpha of release 0.6. But the
``41475`` is a post-release tag, so this version is *newer* than ``0.6a9.dev``.
For the most part, setuptools' interpretation of version numbers is intuitive,
but here are a few tips that will keep you out of trouble in the corner cases:
* Don't stick adjoining pre-release tags together without a dot or number
between them. Version ``1.9adev`` is the ``adev`` prerelease of ``1.9``,
*not* a development pre-release of ``1.9a``. Use ``.dev`` instead, as in
``1.9a.dev``, or separate the prerelease tags with a number, as in
``1.9a0dev``. ``1.9a.dev``, ``1.9a0dev``, and even ``1.9a0.dev0`` are
identical versions from setuptools' point of view, so you can use whatever
scheme you prefer. Of these examples, only ``1.9a0.dev0`` is
:pep:`440`-compliant.
* If you want to be certain that your chosen numbering scheme works the way
you think it will, you can use the ``pkg_resources.parse_version()`` function
to compare different version numbers::
>>> from pkg_resources import parse_version
>>> parse_version("1.9.a.dev") == parse_version("1.9a0dev")
True
>>> parse_version("2.1-rc2") < parse_version("2.1")
True
>>> parse_version("0.6a9dev-r41475") < parse_version("0.6a9")
True
Once you've decided on a version numbering scheme for your project, you can
have setuptools automatically tag your in-development releases with various
pre- or post-release tags. See the following section for more details.
Tagging and "Daily Build" or "Snapshot" Releases
------------------------------------------------
.. warning::
Please note that running ``python setup.py ...`` directly is no longer
considered a good practice and that in the future the commands ``egg_info``
and ``rotate`` will be deprecated.
As a result, the instructions and information presented in this section
should be considered **transitional** while setuptools don't provide a
mechanism for tagging releases.
Meanwhile, if you can also consider using :pypi:`setuptools-scm` to achieve
similar objectives.
When a set of related projects are under development, it may be important to
track finer-grained version increments than you would normally use for e.g.
"stable" releases. While stable releases might be measured in dotted numbers
with alpha/beta/etc. status codes, development versions of a project often
need to be tracked by revision or build number or even build date. This is
especially true when projects in development need to refer to one another, and
therefore may literally need an up-to-the-minute version of something!
To support these scenarios, ``setuptools`` allows you to "tag" your source and
egg distributions by adding one or more of the following to the project's
"official" version identifier:
* A manually-specified pre-release tag, such as "build" or "dev", or a
manually-specified post-release tag, such as a build or revision number
(``--tag-build=STRING, -bSTRING``)
* An 8-character representation of the build date (``--tag-date, -d``), as
a postrelease tag
You can add these tags by adding ``egg_info`` and the desired options to
the command line ahead of the ``sdist`` or ``bdist`` commands that you want
to generate a daily build or snapshot for. See the section below on the
:ref:`egg_info ` command for more details.
(Also, before you release your project, be sure to see the section on
:ref:`Specifying Your Project's Version` for more information about how pre- and
post-release tags affect how version numbers are interpreted. This is
important in order to make sure that dependency processing tools will know
which versions of your project are newer than others).
Finally, if you are creating builds frequently, and either building them in a
downloadable location or are copying them to a distribution server, you should
probably also check out the :ref:`rotate ` command, which lets you automatically
delete all but the N most-recently-modified distributions matching a glob
pattern. So, you can use a command line like::
setup.py egg_info -rbDEV bdist_egg rotate -m.egg -k3
to build an egg whose version info includes "DEV-rNNNN" (where NNNN is the
most recent Subversion revision that affected the source tree), and then
delete any egg files from the distribution directory except for the three
that were built most recently.
If you have to manage automated builds for multiple packages, each with
different tagging and rotation policies, you may also want to check out the
:ref:`alias ` command, which would let each package define an alias like ``daily``
that would perform the necessary tag, build, and rotate commands. Then, a
simpler script or cron job could just run ``setup.py daily`` in each project
directory. (And, you could also define sitewide or per-user default versions
of the ``daily`` alias, so that projects that didn't define their own would
use the appropriate defaults.)
Making "Official" (Non-Snapshot) Releases
-----------------------------------------
When you make an official release, creating source or binary distributions,
you will need to override the tag settings from ``setup.cfg``, so that you
don't end up registering versions like ``foobar-0.7a1.dev-r34832``. This is
easy to do if you are developing on the trunk and using tags or branches for
your releases - just make the change to ``setup.cfg`` after branching or
tagging the release, so the trunk will still produce development snapshots.
Alternately, if you are not branching for releases, you can override the
default version options on the command line, using something like::
setup.py egg_info -Db "" sdist bdist_egg
The first part of this command (``egg_info -Db ""``) will override the
configured tag information, before creating source and binary eggs. Thus, these
commands will use the plain version from your ``setup.py``, without adding the
build designation string.
Of course, if you will be doing this a lot, you may wish to create a personal
alias for this operation, e.g.::
setup.py alias -u release egg_info -Db ""
You can then use it like this::
setup.py release sdist bdist_egg
Or of course you can create more elaborate aliases that do all of the above.
See the sections below on the :ref:`egg_info ` and
:ref:`alias ` commands for more ideas.
././@PaxHeader 0000000 0000000 0000000 00000000026 00000000000 010213 x ustar 00 22 mtime=1692360458.0
setuptools-68.1.2/docs/userguide/entry_point.rst 0000644 0001751 0000173 00000043673 14467657412 021517 0 ustar 00runner docker .. _`entry_points`:
============
Entry Points
============
Entry points are a type of metadata that can be exposed by packages on installation.
They are a very useful feature of the Python ecosystem,
and come specially handy in two scenarios:
1. The package would like to provide commands to be run at the terminal.
This functionality is known as *console* scripts. The command may also
open up a GUI, in which case it is known as a *GUI* script. An example
of a console script is the one provided by the :pypi:`pip` package, which
allows you to run commands like ``pip install`` in the terminal.
2. A package would like to enable customization of its functionalities
via *plugins*. For example, the test framework :pypi:`pytest` allows
customization via the ``pytest11`` entry point, and the syntax
highlighting tool :pypi:`pygments` allows specifying additional styles
using the entry point ``pygments.styles``.
.. _console-scripts:
Console Scripts
===============
Let us start with console scripts.
First consider an example without entry points. Imagine a package
defined thus::
project_root_directory
├── pyproject.toml # and/or setup.cfg, setup.py
└── src
└── timmins
├── __init__.py
└── ...
with ``__init__.py`` as:
.. code-block:: python
def hello_world():
print("Hello world")
Now, suppose that we would like to provide some way of executing the
function ``hello_world()`` from the command-line. One way to do this
is to create a file ``src/timmins/__main__.py`` providing a hook as
follows:
.. code-block:: python
from . import hello_world
if __name__ == '__main__':
hello_world()
Then, after installing the package ``timmins``, we may invoke the ``hello_world()``
function as follows, through the `runpy `_
module:
.. code-block:: bash
$ python -m timmins
Hello world
Instead of this approach using ``__main__.py``, you can also create a
user-friendly CLI executable that can be called directly without ``python -m``.
In the above example, to create a command ``hello-world`` that invokes
``timmins.hello_world``, add a console script entry point to your
configuration:
.. tab:: pyproject.toml
.. code-block:: toml
[project.scripts]
hello-world = "timmins:hello_world"
.. tab:: setup.cfg
.. code-block:: ini
[options.entry_points]
console_scripts =
hello-world = timmins:hello_world
.. tab:: setup.py
.. code-block:: python
from setuptools import setup
setup(
# ...,
entry_points={
'console_scripts': [
'hello-world = timmins:hello_world',
]
}
)
After installing the package, a user may invoke that function by simply calling
``hello-world`` on the command line:
.. code-block:: bash
$ hello-world
Hello world
Note that any function used as a console script, i.e. ``hello_world()`` in
this example, should not accept any arguments. If your function requires any input
from the user, you can use regular command-line argument parsing utilities like
:mod:`argparse` within the body of
the function to parse user input given via :obj:`sys.argv`.
You may have noticed that we have used a special syntax to specify the function
that must be invoked by the console script, i.e. we have written ``timmins:hello_world``
with a colon ``:`` separating the package name and the function name. The full
specification of this syntax is discussed in the `last section <#entry-points-syntax>`_
of this document, and this can be used to specify a function located anywhere in
your package, not just in ``__init__.py``.
GUI Scripts
===========
In addition to ``console_scripts``, Setuptools supports ``gui_scripts``, which
will launch a GUI application without running in a terminal window.
For example, if we have a project with the same directory structure as before,
with an ``__init__.py`` file containing the following:
.. code-block:: python
import PySimpleGUI as sg
def hello_world():
sg.Window(title="Hello world", layout=[[]], margins=(100, 50)).read()
Then, we can add a GUI script entry point:
.. tab:: pyproject.toml
.. code-block:: toml
[project.gui-scripts]
hello-world = "timmins:hello_world"
.. tab:: setup.cfg
.. code-block:: ini
[options.entry_points]
gui_scripts =
hello-world = timmins:hello_world
.. tab:: setup.py
.. code-block:: python
from setuptools import setup
setup(
# ...,
entry_points={
'gui_scripts': [
'hello-world = timmins:hello_world',
]
}
)
.. note::
To be able to import ``PySimpleGUI``, you need to add ``pysimplegui`` to your package dependencies.
See :doc:`/userguide/dependency_management` for more information.
Now, running:
.. code-block:: bash
$ hello-world
will open a small application window with the title 'Hello world'.
Note that just as with console scripts, any function used as a GUI script
should not accept any arguments, and any user input can be parsed within the
body of the function. GUI scripts also use the same syntax (discussed in the
`last section <#entry-points-syntax>`_) for specifying the function to be invoked.
.. note::
The difference between ``console_scripts`` and ``gui_scripts`` only affects
Windows systems. [#use_for_scripts]_ ``console_scripts`` are wrapped in a console
executable, so they are attached to a console and can use ``sys.stdin``,
``sys.stdout`` and ``sys.stderr`` for input and output. ``gui_scripts`` are
wrapped in a GUI executable, so they can be started without a console, but
cannot use standard streams unless application code redirects them. Other
platforms do not have the same distinction.
.. note::
Console and GUI scripts work because behind the scenes, installers like :pypi:`pip`
create wrapper scripts around the function(s) being invoked. For example,
the ``hello-world`` entry point in the above two examples would create a
command ``hello-world`` launching a script like this: [#use_for_scripts]_
.. code-block:: python
import sys
from timmins import hello_world
sys.exit(hello_world())
.. _dynamic discovery of services and plugins:
Advertising Behavior
====================
Console/GUI scripts are one use of the more general concept of entry points. Entry
points more generally allow a packager to advertise behavior for discovery by
other libraries and applications. This feature enables "plug-in"-like
functionality, where one library solicits entry points and any number of other
libraries provide those entry points.
A good example of this plug-in behavior can be seen in
`pytest plugins `_,
where pytest is a test framework that allows other libraries to extend
or modify its functionality through the ``pytest11`` entry point.
The console/GUI scripts work similarly, where libraries advertise their commands
and tools like ``pip`` create wrapper scripts that invoke those commands.
Entry Points for Plugins
========================
Let us consider a simple example to understand how we can implement entry points
corresponding to plugins. Say we have a package ``timmins`` with the following
directory structure::
timmins
├── pyproject.toml # and/or setup.cfg, setup.py
└── src
└── timmins
└── __init__.py
and in ``src/timmins/__init__.py`` we have the following code:
.. code-block:: python
def hello_world():
print('Hello world')
Basically, we have defined a ``hello_world()`` function which will print the text
'Hello world'. Now, let us say we want to print the text 'Hello world' in different
ways. The current function just prints the text as it is - let us say we want another
style in which the text is enclosed within exclamation marks::
!!! Hello world !!!
Let us see how this can be done using plugins. First, let us separate the style of
printing the text from the text itself. In other words, we can change the code in
``src/timmins/__init__.py`` to something like this:
.. code-block:: python
def display(text):
print(text)
def hello_world():
display('Hello world')
Here, the ``display()`` function controls the style of printing the text, and the
``hello_world()`` function calls the ``display()`` function to print the text 'Hello
world`.
Right now the ``display()`` function just prints the text as it is. In order to be able
to customize it, we can do the following. Let us introduce a new *group* of entry points
named ``timmins.display``, and expect plugin packages implementing this entry point
to supply a ``display()``-like function. Next, to be able to automatically discover plugin
packages that implement this entry point, we can use the
:mod:`importlib.metadata` module,
as follows:
.. code-block:: python
from importlib.metadata import entry_points
display_eps = entry_points(group='timmins.display')
.. note::
Each ``importlib.metadata.EntryPoint`` object is an object containing a ``name``, a
``group``, and a ``value``. For example, after setting up the plugin package as
described below, ``display_eps`` in the above code will look like this: [#package_metadata]_
.. code-block:: python
(
EntryPoint(name='excl', value='timmins_plugin_fancy:excl_display', group='timmins.display'),
...,
)
``display_eps`` will now be a list of ``EntryPoint`` objects, each referring to ``display()``-like
functions defined by one or more installed plugin packages. Then, to import a specific
``display()``-like function - let us choose the one corresponding to the first discovered
entry point - we can use the ``load()`` method as follows:
.. code-block:: python
display = display_eps[0].load()
Finally, a sensible behaviour would be that if we cannot find any plugin packages customizing
the ``display()`` function, we should fall back to our default implementation which prints
the text as it is. With this behaviour included, the code in ``src/timmins/__init__.py``
finally becomes:
.. code-block:: python
from importlib.metadata import entry_points
display_eps = entry_points(group='timmins.display')
try:
display = display_eps[0].load()
except IndexError:
def display(text):
print(text)
def hello_world():
display('Hello world')
That finishes the setup on ``timmins``'s side. Next, we need to implement a plugin
which implements the entry point ``timmins.display``. Let us name this plugin
``timmins-plugin-fancy``, and set it up with the following directory structure::
timmins-plugin-fancy
├── pyproject.toml # and/or setup.cfg, setup.py
└── src
└── timmins_plugin_fancy
└── __init__.py
And then, inside ``src/timmins_plugin_fancy/__init__.py``, we can put a function
named ``excl_display()`` that prints the given text surrounded by exclamation marks:
.. code-block:: python
def excl_display(text):
print('!!!', text, '!!!')
This is the ``display()``-like function that we are looking to supply to the
``timmins`` package. We can do that by adding the following in the configuration
of ``timmins-plugin-fancy``:
.. tab:: pyproject.toml
.. code-block:: toml
# Note the quotes around timmins.display in order to escape the dot .
[project.entry-points."timmins.display"]
excl = "timmins_plugin_fancy:excl_display"
.. tab:: setup.cfg
.. code-block:: ini
[options.entry_points]
timmins.display =
excl = timmins_plugin_fancy:excl_display
.. tab:: setup.py
.. code-block:: python
from setuptools import setup
setup(
# ...,
entry_points = {
'timmins.display': [
'excl = timmins_plugin_fancy:excl_display'
]
}
)
Basically, this configuration states that we are a supplying an entry point
under the group ``timmins.display``. The entry point is named ``excl`` and it
refers to the function ``excl_display`` defined by the package ``timmins-plugin-fancy``.
Now, if we install both ``timmins`` and ``timmins-plugin-fancy``, we should get
the following:
.. code-block:: pycon
>>> from timmins import hello_world
>>> hello_world()
!!! Hello world !!!
whereas if we only install ``timmins`` and not ``timmins-plugin-fancy``, we should
get the following:
.. code-block:: pycon
>>> from timmins import hello_world
>>> hello_world()
Hello world
Therefore, our plugin works.
Our plugin could have also defined multiple entry points under the group ``timmins.display``.
For example, in ``src/timmins_plugin_fancy/__init__.py`` we could have two ``display()``-like
functions, as follows:
.. code-block:: python
def excl_display(text):
print('!!!', text, '!!!')
def lined_display(text):
print(''.join(['-' for _ in text]))
print(text)
print(''.join(['-' for _ in text]))
The configuration of ``timmins-plugin-fancy`` would then change to:
.. tab:: pyproject.toml
.. code-block:: toml
[project.entry-points."timmins.display"]
excl = "timmins_plugin_fancy:excl_display"
lined = "timmins_plugin_fancy:lined_display"
.. tab:: setup.cfg
.. code-block:: ini
[options.entry_points]
timmins.display =
excl = timmins_plugin_fancy:excl_display
lined = timmins_plugin_fancy:lined_display
.. tab:: setup.py
.. code-block:: python
from setuptools import setup
setup(
# ...,
entry_points = {
'timmins.display': [
'excl = timmins_plugin_fancy:excl_display',
'lined = timmins_plugin_fancy:lined_display',
]
}
)
On the ``timmins`` side, we can also use a different strategy of loading entry
points. For example, we can search for a specific display style:
.. code-block:: python
display_eps = entry_points(group='timmins.display')
try:
display = display_eps['lined'].load()
except KeyError:
# if the 'lined' display is not available, use something else
...
Or we can also load all plugins under the given group. Though this might not
be of much use in our current example, there are several scenarios in which this
is useful:
.. code-block:: python
display_eps = entry_points(group='timmins.display')
for ep in display_eps:
display = ep.load()
# do something with display
...
Another point is that in this particular example, we have used plugins to
customize the behaviour of a function (``display()``). In general, we can use entry
points to enable plugins to not only customize the behaviour of functions, but also
of entire classes and modules. This is unlike the case of console/GUI scripts,
where entry points can only refer to functions. The syntax used for specifying the
entry points remains the same as for console/GUI scripts, and is discussed in the
`last section <#entry-points-syntax>`_.
.. tip::
The recommended approach for loading and importing entry points is the
:mod:`importlib.metadata` module,
which is a part of the standard library since Python 3.8. For older versions of
Python, its backport :pypi:`importlib_metadata` should be used. While using the
backport, the only change that has to be made is to replace ``importlib.metadata``
with ``importlib_metadata``, i.e.
.. code-block:: python
from importlib_metadata import entry_points
...
In summary, entry points allow a package to open its functionalities for
customization via plugins.
The package soliciting the entry points need not have any dependency
or prior knowledge about the plugins implementing the entry points, and
downstream users are able to compose functionality by pulling together
plugins implementing the entry points.
Entry Points Syntax
===================
The syntax for entry points is specified as follows::
= [: