Minor PEP 453 tweaks
- link to latest discussion thread - new post date - typos
This commit is contained in:
parent
ca04a38403
commit
2ce1f07c01
17
pep-0453.txt
17
pep-0453.txt
|
@ -9,7 +9,8 @@ Status: Draft
|
|||
Type: Process
|
||||
Content-Type: text/x-rst
|
||||
Created: 10-Aug-2013
|
||||
Post-History: 30-Aug-2013, 15-Sep-2013, 18-Sep-2013, 19-Sep-2013, 23-Sep-2013
|
||||
Post-History: 30-Aug-2013, 15-Sep-2013, 18-Sep-2013, 19-Sep-2013,
|
||||
23-Sep-2013, 29-Sep-2013
|
||||
|
||||
|
||||
Abstract
|
||||
|
@ -170,9 +171,10 @@ By contrast, using a separate installer application like ``pip`` (which
|
|||
ensures that even ``setup.py`` files that invoke ``distutils`` directly
|
||||
still support the new packaging standards) makes it possible to support
|
||||
new packaging standards in older versions of Python, just by upgrading
|
||||
``pip``. The situation on older versions of Python is further improved by
|
||||
making it easier for end users to install and upgrade newer build systems
|
||||
like ``setuptools`` or improved PyPI upload utilities like ``twine``.
|
||||
``pip`` (which receives new feature releases roughly every 6 months). The
|
||||
situation on older versions of Python is further improved by making it
|
||||
easier for end users to install and upgrade newer build systems like
|
||||
``setuptools`` or improved PyPI upload utilities like ``twine``.
|
||||
|
||||
It is not coincidental that this proposed model of using a separate installer
|
||||
program with more metadata heavy and less active distribution formats matches
|
||||
|
@ -1054,7 +1056,7 @@ This has been rejected because:
|
|||
Use a different module name in Python 2.7, and 3.3
|
||||
--------------------------------------------------
|
||||
|
||||
Naming the module `_ensurepip`` in Python 2.7 and 3.3 was considered as
|
||||
Naming the module ``_ensurepip`` in Python 2.7 and 3.3 was considered as
|
||||
another means of skirting the "no new features in maintenance releases"
|
||||
policy. However, similar to the proposal to only include the new
|
||||
feature in the installers rather than the standard library, this feels like
|
||||
|
@ -1148,7 +1150,7 @@ system installer never get into a fight about who owns the pip
|
|||
installation (it is always managed through pip, either directly, or
|
||||
indirectly via the ``ensurepip`` bootstrap module).
|
||||
|
||||
Finally, the separate bootstrapping step means it also easy to avoid
|
||||
Finally, the separate bootstrapping step means it is also easy to avoid
|
||||
installing ``pip`` at all if end users so desire. This is often the case
|
||||
if integrators are using system packages to handle installation of
|
||||
components written in multiple languages using a common set of tools.
|
||||
|
@ -1186,6 +1188,9 @@ References
|
|||
.. [4] Discussion thread 4 (python-dev)
|
||||
(https://mail.python.org/pipermail/python-dev/2013-September/128780.html)
|
||||
|
||||
.. [5] Discussion thread 5 (python-dev)
|
||||
(https://mail.python.org/pipermail/python-dev/2013-September/128894.html)
|
||||
|
||||
.. [#ubuntu] `Ubuntu <http://www.ubuntu.com/>`
|
||||
.. [#debian] `Debian <http://www.debian.org>`
|
||||
.. [#fedora] `Fedora <https://fedoraproject.org/>`
|
||||
|
|
Loading…
Reference in New Issue