Skip to content

S
setuptools
Commit e6087bfa authored by Jason R. Coombs's avatar Jason R. Coombs
Browse files
Options

Merge branch 'master' into feature/581-depend-not-bundle

parents 767dcea0 3c182f9f
Hide whitespace changes
Inline Side-by-side
Showing with 65 additions and 182 deletions
CHANGES.rst
View file @ e6087bfa
......@@ -97,7 +97,7 @@ v30.3.0
* #394 via #862: Added support for `declarative package
config in a setup.cfg file
<http://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files>`_.
<https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files>`_.
v30.2.1
-------
......@@ -708,7 +708,7 @@ v20.6.0
`semver <https://semver.org>`_ precisely.
The 'v' prefix on version numbers now also allows
version numbers to be referenced in the changelog,
e.g. https://pythonhosted.org/setuptools/history.html#v20-6-0.
e.g. http://setuptools.readthedocs.io/en/latest/history.html#v20-6-0.
20.5
----
......@@ -788,7 +788,7 @@ v20.6.0
* Added support for using passwords from keyring in the upload
command. See `the upload docs
<http://pythonhosted.org/setuptools/setuptools.html#upload-upload-source-and-or-egg-distributions-to-pypi>`_
<https://setuptools.readthedocs.io/en/latest/setuptools.html#upload-upload-source-and-or-egg-distributions-to-pypi>`_
for details.
20.0
......@@ -1542,7 +1542,7 @@ process to fail and PyPI uploads no longer accept files for 13.0.
---
* Added a `Developer Guide
<https://pythonhosted.org/setuptools/developer-guide.html>`_ to the official
<https://setuptools.readthedocs.io/en/latest/developer-guide.html>`_ to the official
documentation.
* Some code refactoring and cleanup was done with no intended behavioral
changes.
......@@ -2962,7 +2962,7 @@ easy_install
* ``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
<http://pythonhosted.org/setuptools/setuptools.html#creating-distutils-extensions>`_
<https://setuptools.readthedocs.io/en/latest/setuptools.html#creating-distutils-extensions>`_
for more details.
* The vestigial ``depends`` command has been removed. It was never finished
......
MANIFEST.in
View file @ e6087bfa
......@@ -11,3 +11,4 @@ include LICENSE
include launcher.c
include msvc-build-launcher.cmd
include pytest.ini
include tox.ini
README.rst
View file @ e6087bfa
......@@ -126,8 +126,8 @@ Use ``--help`` to get a full options list, but we recommend consulting
the `EasyInstall manual`_ for detailed instructions, especially `the section
on custom installation locations`_.
.. _EasyInstall manual: https://pythonhosted.org/setuptools/EasyInstall
.. _the section on custom installation locations: https://pythonhosted.org/setuptools/EasyInstall#custom-installation-locations
.. _EasyInstall manual: https://setuptools.readthedocs.io/en/latest/easy_install.html
.. _the section on custom installation locations: https://setuptools.readthedocs.io/en/latest/easy_install.html#custom-installation-locations
Downloads
......
docs/setuptools.txt
View file @ e6087bfa
......@@ -59,14 +59,6 @@ Feature Highlights:
* Create extensible applications and frameworks that automatically discover
extensions, using simple "entry points" declared in a project's setup script.
In addition to the PyPI downloads, the development version of ``setuptools``
is available from the `Python SVN sandbox`_, and in-development versions of the
`0.6 branch`_ are available as well.
.. _0.6 branch: http://svn.python.org/projects/sandbox/branches/setuptools-0.6/#egg=setuptools-dev06
.. _Python SVN sandbox: http://svn.python.org/projects/sandbox/trunk/setuptools/#egg=setuptools-dev
.. contents:: **Table of Contents**
.. _ez_setup.py: `bootstrap module`_
......@@ -769,6 +761,40 @@ so that Package B doesn't have to remove the ``[PDF]`` from its requirement
specifier.
.. _Platform Specific Dependencies:
Declaring platform specific dependencies
----------------------------------------
Sometimes a project might require a dependency to run on a specific platform.
This could to a package that back ports a module so that it can be used in
older python versions. Or it could be a package that is required to run on a
specific operating system. This will allow a project to work on multiple
different platforms without installing dependencies that are not required for
a platform that is installing the project.
For example, here is a project that uses the ``enum`` module and ``pywin32``::
setup(
name="Project",
...
install_requires=[
'enum34;python_version<"3.4"',
'pywin32 >= 1.0;platform_system=="Windows"'
]
)
Since the ``enum`` module was added in Python 3.4, it should only be installed
if the python version is earlier. Since ``pywin32`` will only be used on
windows, it should only be installed when the operating system is Windows.
Specifying version requirements for the dependencies is supported as normal.
The environmental markers that may be used for testing platform types are
detailed in `PEP 508`_.
.. _PEP 508: https://www.python.org/dev/peps/pep-0508/
Including Data Files
====================
......@@ -1422,10 +1448,6 @@ egg distributions by adding one or more of the following to the project's
manually-specified post-release tag, such as a build or revision number
(``--tag-build=STRING, -bSTRING``)
* A "last-modified revision number" string generated automatically from
Subversion's metadata (assuming your project is being built from a Subversion
"working copy") (``--tag-svn-revision, -r``)
* An 8-character representation of the build date (``--tag-date, -d``), as
a postrelease tag
......@@ -1557,68 +1579,6 @@ this::
in order to check out the in-development version of ``projectname``.
Managing "Continuous Releases" Using Subversion
-----------------------------------------------
If you expect your users to track in-development versions of your project via
Subversion, there are a few additional steps you should take to ensure that
things work smoothly with EasyInstall. First, you should add the following
to your project's ``setup.cfg`` file:
.. code-block:: ini
[egg_info]
tag_build = .dev
tag_svn_revision = 1
This will tell ``setuptools`` to generate package version numbers like
``1.0a1.dev-r1263``, which will be considered to be an *older* release than
``1.0a1``. Thus, when you actually release ``1.0a1``, the entire egg
infrastructure (including ``setuptools``, ``pkg_resources`` and EasyInstall)
will know that ``1.0a1`` supersedes any interim snapshots from Subversion, and
handle upgrades accordingly.
(Note: the project version number you specify in ``setup.py`` should always be
the *next* version of your software, not the last released version.
Alternately, you can leave out the ``tag_build=.dev``, and always use the
*last* release as a version number, so that your post-1.0 builds are labelled
``1.0-r1263``, indicating a post-1.0 patchlevel. Most projects so far,
however, seem to prefer to think of their project as being a future version
still under development, rather than a past version being patched. It is of
course possible for a single project to have both situations, using
post-release numbering on release branches, and pre-release numbering on the
trunk. But you don't have to make things this complex if you don't want to.)
Commonly, projects releasing code from Subversion will include a PyPI link to
their checkout URL (as described in the previous section) with an
``#egg=projectname-dev`` suffix. This allows users to request EasyInstall
to download ``projectname==dev`` in order to get the latest in-development
code. Note that if your project depends on such in-progress code, you may wish
to specify your ``install_requires`` (or other requirements) to include
``==dev``, e.g.:
.. code-block:: python
install_requires=["OtherProject>=0.2a1.dev-r143,==dev"]
The above example says, "I really want at least this particular development
revision number, but feel free to follow and use an ``#egg=OtherProject-dev``
link if you find one". This avoids the need to have actual source or binary
distribution snapshots of in-development code available, just to be able to
depend on the latest and greatest a project has to offer.
A final note for Subversion development: if you are using SVN revision tags
as described in this section, it's a good idea to run ``setup.py develop``
after each Subversion checkin or update, because your project's version number
will be changing, and your script wrappers need to be updated accordingly.
Also, if the project's requirements have changed, the ``develop`` command will
take care of fetching the updated dependencies, building changed extensions,
etc. Be sure to also remind any of your users who check out your project
from Subversion that they need to run ``setup.py develop`` after every update
in order to keep their checkout completely in sync.
Making "Official" (Non-Snapshot) Releases
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
......@@ -1632,18 +1592,18 @@ 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::
python setup.py egg_info -RDb "" sdist bdist_egg register upload
python setup.py egg_info -Db "" sdist bdist_egg register upload
The first part of this command (``egg_info -RDb ""``) will override the
The first part of this command (``egg_info -Db ""``) will override the
configured tag information, before creating source and binary eggs, registering
the project with PyPI, and uploading the files. Thus, these commands will use
the plain version from your ``setup.py``, without adding the Subversion
revision number or build designation string.
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.::
python setup.py alias -u release egg_info -RDb ""
python setup.py alias -u release egg_info -Db ""
You can then use it like this::
......@@ -1703,8 +1663,7 @@ 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-svn-revision \
--tag-build=development
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.::
......@@ -1714,7 +1673,7 @@ e.g.::
setup.py daily sdist bdist_egg # generate both
The above commands are interpreted as if the word ``daily`` were replaced with
``egg_info --tag-svn-revision --tag-build=development``.
``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
......@@ -2001,27 +1960,6 @@ added in the following order:
it on the command line using ``-b ""`` or ``--tag-build=""`` as an argument
to the ``egg_info`` command.
``--tag-svn-revision, -r``
If the current directory is a Subversion checkout (i.e. has a ``.svn``
subdirectory, this appends a string of the form "-rNNNN" to the project's
version string, where NNNN is the revision number of the most recent
modification to the current directory, as obtained from the ``svn info``
command.
If the current directory is not a Subversion checkout, the command will
look for a ``PKG-INFO`` file instead, and try to find the revision number
from that, by looking for a "-rNNNN" string at the end of the version
number. (This is so that building a package from a source distribution of
a Subversion snapshot will produce a binary with the correct version
number.)
If there is no ``PKG-INFO`` file, or the version number contained therein
does not end with ``-r`` and a number, then ``-r0`` is used.
``--no-svn-revision, -R``
Don't include the Subversion revision in the version number. This option
is included so you can override a default setting put in ``setup.cfg``.
``--tag-date, -d``
Add a date stamp of the form "-YYYYMMDD" (e.g. "-20050528") to the
project's version number.
......@@ -2335,68 +2273,6 @@ password from the keyring.
New in 20.1: Added keyring support.
.. _upload_docs:
``upload_docs`` - Upload package documentation to PyPI
======================================================
PyPI now supports uploading project documentation to the dedicated URL
https://pythonhosted.org/<project>/.
The ``upload_docs`` command will create the necessary zip file out of a
documentation directory and will post to the repository.
Note that to upload the documentation of a project, the corresponding version
must already be registered with PyPI, using the distutils ``register``
command -- just like the ``upload`` command.
Assuming there is an ``Example`` project with documentation in the
subdirectory ``docs``, e.g.::
Example/
|-- example.py
|-- setup.cfg
|-- setup.py
|-- docs
| |-- build
| | `-- html
| | | |-- index.html
| | | `-- tips_tricks.html
| |-- conf.py
| |-- index.txt
| `-- tips_tricks.txt
You can simply pass the documentation directory path to the ``upload_docs``
command::
python setup.py upload_docs --upload-dir=docs/build/html
If no ``--upload-dir`` is given, ``upload_docs`` will attempt to run the
``build_sphinx`` command to generate uploadable documentation.
For the command to become available, `Sphinx <http://sphinx.pocoo.org/>`_
must be installed in the same environment as distribute.
As with other ``setuptools``-based commands, you can define useful
defaults in the ``setup.cfg`` of your Python project, e.g.:
.. code-block:: ini
[upload_docs]
upload-dir = docs/build/html
The ``upload_docs`` command has the following options:
``--upload-dir``
The directory to be uploaded to the repository.
``--show-response``
Display the full response text from server; this is useful for debugging
PyPI problems.
``--repository=URL, -r URL``
The URL of the repository to upload to. Defaults to
https://pypi.python.org/pypi (i.e., the main PyPI installation).
-----------------------------------------
Configuring setup() using setup.cfg files
......
setup.cfg
View file @ e6087bfa
......@@ -8,11 +8,10 @@ tag_build = .post
tag_date = 1
[aliases]
clean_egg_info = egg_info -RDb ''
clean_egg_info = egg_info -Db ''
release = clean_egg_info sdist bdist_wheel
source = register sdist binary
binary = bdist_egg upload --show-response
test = pytest
[upload]
repository = https://upload.pypi.org/legacy/
......
setuptools/command/egg_info.py
View file @ e6087bfa
......@@ -121,18 +121,13 @@ class egg_info(Command):
user_options = [
('egg-base=', 'e', "directory containing .egg-info directories"
" (default: top of the source tree)"),
('tag-svn-revision', 'r',
"Add subversion revision ID to version number"),
('tag-date', 'd', "Add date stamp (e.g. 20050528) to version number"),
('tag-build=', 'b', "Specify explicit tag to add to version number"),
('no-svn-revision', 'R',
"Don't add subversion revision ID [default]"),
('no-date', 'D', "Don't include date stamp [default]"),
]
boolean_options = ['tag-date', 'tag-svn-revision']
boolean_options = ['tag-date']
negative_opt = {
'no-svn-revision': 'tag-svn-revision',
'no-date': 'tag-date',
}
......@@ -146,10 +141,22 @@ class egg_info(Command):
self.broken_egg_info = False
self.vtags = None
####################################
# allow the 'tag_svn_revision' to be detected and
# set, supporting sdists built on older Setuptools.
@property
def tag_svn_revision(self):
pass
@tag_svn_revision.setter
def tag_svn_revision(self, value):
pass
####################################
def save_version_info(self, filename):
"""
Materialize the values of svn_revision and date into the
build tag. Install these keys in a deterministic order
Materialize the value of date into the
build tag. Install build keys in a deterministic order
to avoid arbitrary reordering on subsequent builds.
"""
# python 2.6 compatibility
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7