[Python-checkins] distutils2: Fix some familiar typos and use consistent spellings
tarek.ziade
python-checkins at python.org
Thu Aug 19 08:34:12 CEST 2010
tarek.ziade pushed a4288f137770 to distutils2:
http://hg.python.org/distutils2/rev/a4288f137770
changeset: 531:a4288f137770
user: ?ric Araujo <merwok at netwok.org>
date: Mon Aug 09 09:28:11 2010 +0200
summary: Fix some familiar typos and use consistent spellings
files: docs/design/pep-0376.txt, docs/source/apiref.rst, docs/source/builtdist.rst, docs/source/configfile.rst, docs/source/depgraph.rst, docs/source/examples.rst, docs/source/extending.rst, docs/source/packageindex.rst, docs/source/pkgutil.rst, docs/source/projects-index.simple.rst, docs/source/setupscript.rst, docs/source/test_framework.rst, src/distutils2/command/build_ext.py, src/distutils2/command/cmd.py, src/distutils2/compiler/bcppcompiler.py, src/distutils2/compiler/ccompiler.py, src/distutils2/core.py, src/distutils2/dist.py, src/distutils2/fancy_getopt.py, src/distutils2/tests/test_dist.py, src/setup.py
diff --git a/docs/design/pep-0376.txt b/docs/design/pep-0376.txt
--- a/docs/design/pep-0376.txt
+++ b/docs/design/pep-0376.txt
@@ -415,7 +415,7 @@
A new class called ``Distribution`` is created with the path of the
`.egg-info` directory provided to the constructor. It reads the metadata
-contained in `PKG-INFO` when it is instanciated.
+contained in `PKG-INFO` when it is instantiated.
``Distribution(path)`` -> instance
diff --git a/docs/source/apiref.rst b/docs/source/apiref.rst
--- a/docs/source/apiref.rst
+++ b/docs/source/apiref.rst
@@ -90,8 +90,8 @@
+--------------------+--------------------------------+-------------------------------------------------------------+
| *license* | The license for the package | a string |
+--------------------+--------------------------------+-------------------------------------------------------------+
- | *keywords* | Descriptive meta-data, see | |
- | | :pep:`314` | |
+ | *keywords* | Descriptive metadata, see | |
+ | | :PEP:`314` | |
+--------------------+--------------------------------+-------------------------------------------------------------+
| *platforms* | | |
+--------------------+--------------------------------+-------------------------------------------------------------+
@@ -111,9 +111,9 @@
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
+ useful if you need to find out the distribution metadata (passed as keyword
args from *script* to :func:`setup`), or the contents of the config files or
- command-line.
+ command line.
*script_name* is a file that will be run with :func:`execfile` ``sys.argv[0]``
will be replaced with *script* for the duration of the call. *script_args* is a
@@ -133,7 +133,7 @@
| | (and their data stored in the |
| | :class:`Distribution` instance) |
+---------------+---------------------------------------------+
- | *commandline* | Stop after the command-line |
+ | *commandline* | Stop after the command line |
| | (``sys.argv[1:]`` or *script_args*) have |
| | been parsed (and the data stored in the |
| | :class:`Distribution` instance.) |
@@ -305,7 +305,7 @@
.. function:: gen_preprocess_options(macros, include_dirs)
- Generate C pre-processor options (:option:`-D`, :option:`-U`, :option:`-I`) as
+ Generate C preprocessor 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
@@ -535,7 +535,7 @@
| *archiver* | static library creator |
+--------------+------------------------------------------+
- On platforms with a command-line (Unix, DOS/Windows), each of these is a string
+ 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
@@ -574,7 +574,7 @@
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
+ 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
@@ -770,7 +770,7 @@
This module provides the :class:`UnixCCompiler` class, a subclass of
-:class:`CCompiler` that handles the typical Unix-style command-line C compiler:
+:class:`CCompiler` that handles the typical Unix-style command-line C compiler:
* macros defined with :option:`-Dname[=value]`
@@ -1707,15 +1707,15 @@
.. % todo
-:mod:`distutils.command.check` --- Check the meta-data of a package
-===================================================================
+:mod:`distutils.command.check` --- Check the metadata of a package
+==================================================================
.. module:: distutils.command.check
:synopsis: Check the metadata 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 ``check`` command performs some tests on the metadata of a package.
+For example, it verifies that all required metadata are provided as
the arguments passed to the :func:`setup` function.
.. % todo
@@ -1741,7 +1741,7 @@
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
+ 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.
@@ -1750,7 +1750,7 @@
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
+ command line or from other commands have been done. Thus, this is the place
to 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`.
@@ -1760,7 +1760,7 @@
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
+ 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`.
@@ -2000,17 +2000,17 @@
The ``register`` command registers the package with the Python Package Index.
-This is described in more detail in :pep:`301`.
+This is described in more detail in :PEP:`301`.
.. % todo
-:mod:`distutils.command.check` --- Check the meta-data of a package
-===================================================================
+:mod:`distutils.command.check` --- Check the metadata of a package
+==================================================================
.. module:: distutils.command.check
:synopsis: Check the metadata 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 ``check`` command performs some tests on the metadata of a package.
+For example, it verifies that all required metadata are provided as
the arguments passed to the :func:`setup` function.
diff --git a/docs/source/builtdist.rst b/docs/source/builtdist.rst
--- a/docs/source/builtdist.rst
+++ b/docs/source/builtdist.rst
@@ -236,7 +236,7 @@
| Icon | :option:`icon` | (none) |
+-------------------------------+-----------------------------+-------------------------+
-Obviously, supplying even a few of these options on the command-line would be
+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
@@ -436,7 +436,7 @@
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
+ 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`
diff --git a/docs/source/configfile.rst b/docs/source/configfile.rst
--- a/docs/source/configfile.rst
+++ b/docs/source/configfile.rst
@@ -11,14 +11,14 @@
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.
+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
+---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
+setup script, but before the command line. This has several useful
consequences:
.. If you have more advanced needs, such as determining which extensions to
@@ -63,19 +63,19 @@
--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
+ --swig-opts list of SWIG command-line options
[...]
.. XXX do we want to support ``setup.py --help metadata``?
-Note that an option spelled :option:`--foo-bar` on the command-line is spelled
+Note that an option spelled :option:`--foo-bar` on the command line is spelled
:option:`foo_bar` in configuration files.
For example, say you want your extensions to be built "in-place"---that is, you
have an extension :mod:`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 :mod:`pkg.mod1` and :mod:`pkg.mod2`. You can always use the
-:option:`--inplace` option on the command-line to ensure this::
+:option:`--inplace` option on the command line to ensure this::
python setup.py build_ext --inplace
@@ -102,7 +102,7 @@
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'
+on the command line for every run. Hence, here is a snippet from the Distutils'
own :file:`setup.cfg`::
[bdist_rpm]
diff --git a/docs/source/depgraph.rst b/docs/source/depgraph.rst
--- a/docs/source/depgraph.rst
+++ b/docs/source/depgraph.rst
@@ -60,7 +60,7 @@
Now, we proceed with generating a graphical representation of the graph. First
we write it to a file, and then we generate a PNG image using the ``dot``
-command line tool::
+command-line tool::
from distutils2.depgraph import graph_to_dot
f = open('output.dot', 'w')
diff --git a/docs/source/examples.rst b/docs/source/examples.rst
--- a/docs/source/examples.rst
+++ b/docs/source/examples.rst
@@ -318,7 +318,7 @@
>>> metadata.description
'Easily download, build, install, upgrade, and uninstall Python packages'
-Notice that the class can also be instanciated with a metadata file path to
+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'
diff --git a/docs/source/extending.rst b/docs/source/extending.rst
--- a/docs/source/extending.rst
+++ b/docs/source/extending.rst
@@ -79,7 +79,7 @@
:mod:`distutils.command`, :mod:`distcmds`, and :mod:`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
+command-line option above, the command :command:`bdist_openpkg` could be
implemented by the class :class:`distcmds.bdist_openpkg.bdist_openpkg` or
:class:`buildcmds.bdist_openpkg.bdist_openpkg`.
diff --git a/docs/source/packageindex.rst b/docs/source/packageindex.rst
--- a/docs/source/packageindex.rst
+++ b/docs/source/packageindex.rst
@@ -4,9 +4,9 @@
Registering with the Package Index
**********************************
-The Python Package Index (PyPI) holds meta-data describing distributions
+The Python Package Index (PyPI) holds metadata describing distributions
packaged with distutils. The distutils command :command:`register` is used to
-submit your distribution's meta-data to the index. It is invoked as follows::
+submit your distribution's metadata to the index. It is invoked as follows::
python setup.py register
@@ -30,10 +30,10 @@
Once you are registered, you may choose option 1 from the menu. You will be
prompted for your PyPI username and password, and :command:`register` will then
-submit your meta-data to the index.
+submit your metadata to the index.
You may submit any number of versions of your distribution to the index. If you
-alter the meta-data for a particular version, you may submit it again and the
+alter the metadata for a particular version, you may submit it again and the
index will be updated.
PyPI holds a record for each (name, version) combination submitted. The first
diff --git a/docs/source/pkgutil.rst b/docs/source/pkgutil.rst
--- a/docs/source/pkgutil.rst
+++ b/docs/source/pkgutil.rst
@@ -6,9 +6,9 @@
============
This module provides the necessary functions to provide support for
-the "Importer Protocol" as described in :pep:`302` and for working with
+the "Importer Protocol" as described in :PEP:`302` and for working with
the database of installed Python distributions which is specified in
-:pep:`376`. In addition to the functions required in :pep:`376`, back support
+:PEP:`376`. In addition to the functions required in :PEP:`376`, back support
for older ``.egg`` and ``.egg-info`` distributions is provided as well. These
distributions are represented by the class
:class:`distutils2._backport.pkgutil.EggInfoDistribution` and
diff --git a/docs/source/projects-index.simple.rst b/docs/source/projects-index.simple.rst
--- a/docs/source/projects-index.simple.rst
+++ b/docs/source/projects-index.simple.rst
@@ -85,7 +85,7 @@
downloads.
It's possible to tell the PyPIClient to follow external links by setting the
-`follow_externals` attribute, on instanciation or after::
+`follow_externals` attribute, on instantiation or after::
>>> client = Crawler(follow_externals=True)
@@ -112,7 +112,7 @@
You also can specify mirrors to fallback on in case the first index_url you
provided doesnt respond, or not correctly. The default behavior for
`Crawler` is to use the list provided by Python.org DNS records, as
-described in the :pep:`381` about mirroring infrastructure.
+described in the :PEP:`381` about mirroring infrastructure.
If you don't want to rely on these, you could specify the list of mirrors you
want to try by specifying the `mirrors` attribute. It's a simple iterable::
diff --git a/docs/source/setupscript.rst b/docs/source/setupscript.rst
--- a/docs/source/setupscript.rst
+++ b/docs/source/setupscript.rst
@@ -4,13 +4,13 @@
Writing the Setup Script
************************
-The setup script is the centre of all activity in building, distributing, and
+The setup script is the center 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:`setup`, and most information supplied to the Distutils by the module
-developer is supplied as keyword arguments to :func:`setup`.
+:ref:`distutils-simple-example` above, the setup script consists mainly of a
+call to :func:`setup`, and most information supplied to the Distutils by the
+module developer is supplied as keyword arguments to :func:`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
@@ -33,12 +33,12 @@
)
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`.
+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 metadata, see section :ref:`metadata`.
Note that any pathnames (files or directories) supplied in the setup script
should be written using the Unix convention, i.e. slash-separated. The
@@ -112,7 +112,8 @@
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::
+section :ref:`distutils-simple-example`; here is a slightly more involved
+example::
py_modules = ['mod1', 'pkg.mod2']
@@ -218,7 +219,7 @@
py_modules=['foo'],
)
-Or on the commandline like this::
+Or on the command line like this::
> python setup.py build_ext --swig-opts="-modern -I../include"
@@ -278,7 +279,7 @@
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
+You can define and undefine preprocessor 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``
@@ -343,7 +344,7 @@
compiler is used.
:option:`extra_compile_args` and :option:`extra_link_args` can be used to
-specify additional command line options for the respective compiler and linker
+specify additional command-line options for the respective compiler and linker
command lines.
:option:`export_symbols` is only useful on Windows. It can contain a list of
@@ -549,12 +550,12 @@
-.. _meta-data:
+.. _metadata:
-Additional meta-data
-====================
+Additional metadata
+===================
-The setup script may include additional meta-data beyond the name and version.
+The setup script may include additional metadata beyond the name and version.
This information includes:
+----------------------+---------------------------+-----------------+--------+
diff --git a/docs/source/test_framework.rst b/docs/source/test_framework.rst
--- a/docs/source/test_framework.rst
+++ b/docs/source/test_framework.rst
@@ -78,7 +78,7 @@
def test_somthing(self, server):
# your tests goes here
-The decorator will instanciate the server for you, and run and stop it just
+The decorator will instantiate the server for you, and run and stop it just
before and after your method call. You also can pass the server initializer,
just like this::
diff --git a/src/distutils2/command/build_ext.py b/src/distutils2/command/build_ext.py
--- a/src/distutils2/command/build_ext.py
+++ b/src/distutils2/command/build_ext.py
@@ -101,7 +101,7 @@
('swig-cpp', None,
"make SWIG create C++ files (default is C)"),
('swig-opts=', None,
- "list of SWIG command line options"),
+ "list of SWIG command-line options"),
('swig=', None,
"path to the SWIG executable"),
]
@@ -384,7 +384,7 @@
self.compiler_obj.initialize(self.plat_name)
# And make sure that any compile/link-related options (which might
- # come from the command-line or from the setup script) are set in
+ # come from the command line or from the setup script) are set in
# that CCompiler object -- that way, they automatically apply to
# all compiling and linking done here.
if self.include_dirs is not None:
@@ -471,7 +471,7 @@
# guess it's useful)
# The environment variable should take precedence, and
# any sensible compiler will give precedence to later
- # command line args. Hence we combine them in order:
+ # command-line args. Hence we combine them in order:
extra_args = ext.extra_compile_args or []
macros = ext.define_macros[:]
diff --git a/src/distutils2/command/cmd.py b/src/distutils2/command/cmd.py
--- a/src/distutils2/command/cmd.py
+++ b/src/distutils2/command/cmd.py
@@ -97,7 +97,7 @@
# just to be safe.
self.force = None
- # The 'help' flag is just used for command-line parsing, so
+ # The 'help' flag is just used for command line parsing, so
# none of that complicated bureaucracy is needed.
self.help = 0
@@ -128,7 +128,7 @@
# finalize_options()
# decide on the final values for all options; this is called
# after all possible intervention from the outside world
- # (command-line, option file, etc.) has been processed
+ # (command line, option file, etc.) has been processed
# run()
# run the command: do whatever it is we're here to do,
# controlled by the command's various option values
@@ -137,7 +137,7 @@
"""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
+ command line. Thus, this is not the place to code dependencies
between options; generally, 'initialize_options()' implementations
are just a bunch of "self.foo = None" assignments.
@@ -149,7 +149,7 @@
def finalize_options(self):
"""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
+ 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
@@ -179,7 +179,7 @@
"""A command's raison d'etre: carry out the action it exists to
perform, controlled by the options initialized in
'initialize_options()', customized by other commands, the setup
- script, the command-line, and config files, and finalized in
+ script, the command line and config files, and finalized in
'finalize_options()'. All terminal output and filesystem
interaction should be done by 'run()'.
diff --git a/src/distutils2/compiler/bcppcompiler.py b/src/distutils2/compiler/bcppcompiler.py
--- a/src/distutils2/compiler/bcppcompiler.py
+++ b/src/distutils2/compiler/bcppcompiler.py
@@ -249,7 +249,7 @@
# list of object files
ld_args.extend(objects)
- # XXX the command-line syntax for Borland C++ is a bit wonky;
+ # XXX the command line syntax for Borland C++ is a bit wonky;
# certain filenames are jammed together in one big string, but
# comma-delimited. This doesn't mesh too well with the
# Unix-centric attitude (with a DOS/Windows quoting hack) of
diff --git a/src/distutils2/compiler/ccompiler.py b/src/distutils2/compiler/ccompiler.py
--- a/src/distutils2/compiler/ccompiler.py
+++ b/src/distutils2/compiler/ccompiler.py
@@ -191,7 +191,7 @@
linker_exe linker used to create binary executables
archiver static library creator
- On platforms with a command-line (Unix, DOS/Windows), each of these
+ 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
@@ -597,7 +597,7 @@
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,
+ 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 prepand/append to the compiler command
line. On other platforms, consult the implementation class
diff --git a/src/distutils2/core.py b/src/distutils2/core.py
--- a/src/distutils2/core.py
+++ b/src/distutils2/core.py
@@ -86,7 +86,7 @@
and the next command are used to set attributes of the current command
object.
- When the entire command-line has been successfully parsed, calls the
+ When the entire command line has been successfully parsed, calls the
'run()' method on each command object in turn. This method will be
driven entirely by the Distribution object (which each command object
has a reference to, thanks to its constructor), and the
@@ -127,7 +127,7 @@
return dist
# Parse the command line and override config files; any
- # command-line errors are the end user's fault, so turn them into
+ # command line errors are the end user's fault, so turn them into
# SystemExit to suppress tracebacks.
try:
ok = dist.parse_command_line()
@@ -159,7 +159,7 @@
return the Distribution instance that drives things. This is useful
if you need to find out the distribution metadata (passed as
keyword args from 'script' to 'setup()', or the contents of the
- config files or command-line.
+ config files or command line.
'script_name' is a file that will be run with 'execfile()';
'sys.argv[0]' will be replaced with 'script' for the duration of the
@@ -176,8 +176,8 @@
stop after config files have been parsed (and their data
stored in the Distribution instance)
commandline
- stop after the command-line ('sys.argv[1:]' or 'script_args')
- have been parsed (and the data stored in the Distribution)
+ stop after the command line ('sys.argv[1:]' or 'script_args')
+ has been parsed (and the data stored in the Distribution)
run [default]
stop after all commands have been run (the same as if 'setup()'
had been called in the usual way
diff --git a/src/distutils2/dist.py b/src/distutils2/dist.py
--- a/src/distutils2/dist.py
+++ b/src/distutils2/dist.py
@@ -162,12 +162,12 @@
# 'script_name' and 'script_args' are usually set to sys.argv[0]
# and sys.argv[1:], but they can be overridden when the caller is
- # not necessarily a setup script run from the command-line.
+ # not necessarily a setup script run from the command line.
self.script_name = None
self.script_args = None
# 'command_options' is where we store command options between
- # parsing them (from config files, the command-line, etc.) and when
+ # parsing them (from config files, the command line, etc.) and when
# they are actually needed -- ie. when the command in question is
# instantiated. It is a dictionary of dictionaries of 2-tuples:
# command_options = { command_name : { option : (source, value) } }
@@ -422,9 +422,9 @@
command class -- thus, we have to be able to load command classes
in order to parse the command line. Any error in that 'options'
attribute raises DistutilsGetoptError; any error on the
- command-line raises DistutilsArgError. If no Distutils commands
+ command line raises DistutilsArgError. If no Distutils commands
were found on the command line, raises DistutilsArgError. Return
- true if command-line was successfully parsed and we should carry
+ true if command line was successfully parsed and we should carry
on with executing commands; false if no errors but we shouldn't
execute commands (currently, this only happens if user asks for
help).
@@ -571,7 +571,7 @@
if help_option_found:
return
- # Put the options from the command-line into their official
+ # Put the options from the command line into their official
# holding pen, the 'command_options' dictionary.
opt_dict = self.get_option_dict(command)
for (name, value) in vars(opts).items():
@@ -592,7 +592,7 @@
def _show_help(self, parser, global_options=1, display_options=1,
commands=[]):
- """Show help for the setup script command-line in the form of
+ """Show help for the setup script command line in the form of
several lists of command-line options. 'parser' should be a
FancyGetopt instance; do not expect it to be returned in the
same state, as its option table will be reset to make it
diff --git a/src/distutils2/fancy_getopt.py b/src/distutils2/fancy_getopt.py
--- a/src/distutils2/fancy_getopt.py
+++ b/src/distutils2/fancy_getopt.py
@@ -71,7 +71,7 @@
# These keep track of the information in the option table. We
# don't actually populate these structures until we're ready to
- # parse the command-line, since the 'option_table' passed in here
+ # parse the command line, since the 'option_table' passed in here
# isn't necessarily the final word.
self.short_opts = []
self.long_opts = []
@@ -80,7 +80,7 @@
self.takes_arg = {}
# And 'option_order' is filled up in 'getopt()'; it records the
- # original order of options (and their values) on the command-line,
+ # original order of options (and their values) on the command line,
# but expands short options, converts aliases, etc.
self.option_order = []
diff --git a/src/distutils2/tests/test_dist.py b/src/distutils2/tests/test_dist.py
--- a/src/distutils2/tests/test_dist.py
+++ b/src/distutils2/tests/test_dist.py
@@ -245,7 +245,7 @@
self.assertRaises(ValueError, dist.announce, args, kwargs)
def test_find_config_files_disable(self):
- # Ticket #1180: Allow user to disable their home config file.
+ # Bug #1180: Allow users to disable their own config file.
temp_home = self.mkdtemp()
if os.name == 'posix':
user_filename = os.path.join(temp_home, ".pydistutils.cfg")
diff --git a/src/setup.py b/src/setup.py
--- a/src/setup.py
+++ b/src/setup.py
@@ -104,7 +104,7 @@
add_dir_to_list(compiler.library_dirs, '/usr/lib')
add_dir_to_list(compiler.include_dirs, '/usr/include')
- # look in command line supplied paths
+ # look in paths supplied on the command line
if SSL_LIBDIR:
add_dir_to_list(compiler.library_dirs, SSL_LIBDIR)
if SSL_INCDIR:
--
Repository URL: http://hg.python.org/distutils2
More information about the Python-checkins
mailing list