typos and a roadmap section
This commit is contained in:
parent
44dc432378
commit
aab3dfac57
30
pep-0376.txt
30
pep-0376.txt
|
@ -30,8 +30,7 @@ Once installed, one or several **packages** are added in Python's site-packages.
|
|||
Rationale
|
||||
=========
|
||||
|
||||
There are three problems right now in the way projects are installed in
|
||||
Python:
|
||||
There are two problems right now in the way projects are installed in Python:
|
||||
|
||||
- There are too many ways to install a project in Python.
|
||||
- There is no API to get the metadata of installed packages.
|
||||
|
@ -46,7 +45,7 @@ command.
|
|||
The `install_egg_info` subcommand is called during this process, in order to
|
||||
create an `.egg-info` file in the `site-packages` directory.
|
||||
|
||||
For example, if the `zlib` project is installed (which contains one package),
|
||||
For example, if the `zlib` project (which contains one package), is installed
|
||||
two elements will be installed in `site-packages`::
|
||||
|
||||
- zlib
|
||||
|
@ -131,7 +130,7 @@ time.
|
|||
|
||||
- the `RECORD` file will hold the list of installed files. These
|
||||
correspond to the files listed by the `record` option of the `install`
|
||||
command, and will always be generated. This will allow uninstall, as
|
||||
command, and will always be generated. This will allow uninstallation, as
|
||||
explained later in this PEP.
|
||||
|
||||
The `install` command will record by default installed files in the
|
||||
|
@ -142,12 +141,11 @@ RECORD file, using these rules:
|
|||
system. This makes this information cross-compatible and allows simple
|
||||
installation to be relocatable.
|
||||
|
||||
- if the installed file is located elswhere in the system, a
|
||||
- if the installed file is located elsewhere in the system, a
|
||||
'/'-separated absolute path is used.
|
||||
|
||||
This will require changing the way the `install` command writes the record
|
||||
file, so the old `record` behavior will be deprecated.
|
||||
XXX see how to handle old record (new option, or wait for 2 version?)
|
||||
|
||||
Back to our `zlib` example, we will have::
|
||||
|
||||
|
@ -205,11 +203,12 @@ the `install` command over the `setup.py` script of the distribution.
|
|||
|
||||
Distutils will provide a very basic `uninstall` command that will remove
|
||||
all files listed in the `RECORD` file of a project, as long as they are not
|
||||
mentioned in another `RECORD` file.
|
||||
mentioned in another `RECORD` file and as long as the package is installed
|
||||
using the standard described earlier.
|
||||
|
||||
This command will be added in the `util` module and will take the name
|
||||
of the project to uninstall. A call to uninstall will return a list
|
||||
of uninstalled files. If the project is not found, a Distutils::
|
||||
This command will be added in ``distutils.util`` and will take the name
|
||||
of the project to uninstall as its argument. A call to uninstall will return a
|
||||
list of uninstalled files::
|
||||
|
||||
>>> from distutils.util import uninstall
|
||||
>>> uninstall('zlib')
|
||||
|
@ -219,9 +218,9 @@ of uninstalled files. If the project is not found, a Distutils::
|
|||
If the project is not found, a ``DistutilsUninstallError`` will be raised.
|
||||
|
||||
To make it a reference API for third-party projects that wish to provide
|
||||
an `uninstall feature`. The `uninstall` API can also be invoked with a
|
||||
an `uninstall feature`. The ``uninstall`` function can also be invoked with a
|
||||
second callable argument, that will be invoked for each file to be removed.
|
||||
If it returns `True`, the file will be removed.
|
||||
If this callable returns `True`, the file will be removed.
|
||||
|
||||
Examples::
|
||||
|
||||
|
@ -235,6 +234,13 @@ Examples::
|
|||
... return False
|
||||
>>> uninstall('zlib', _dry_run)
|
||||
|
||||
Backward compatibility and roadmap
|
||||
==================================
|
||||
|
||||
These changes will not introduce any compatibility problems with the previous
|
||||
version of Distutils, and will also work with existing third-party tools.
|
||||
|
||||
The plan is to integrate them for Python 2.7 and Python 3.2
|
||||
|
||||
Aknowledgments
|
||||
==============
|
||||
|
|
Loading…
Reference in New Issue