Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 349d558

Browse files
committed
#9223: link to Command class reference, and move Command interface docs nearer to class docs.
1 parent 05bfcc5 commit 349d558

2 files changed

Lines changed: 82 additions & 78 deletions

File tree

Doc/distutils/apiref.rst

Lines changed: 80 additions & 76 deletions
Original file line numberDiff line numberDiff line change
@@ -147,11 +147,11 @@ setup script). Indirectly provides the :class:`distutils.dist.Distribution` and
147147
In addition, the :mod:`distutils.core` module exposed a number of classes that
148148
live elsewhere.
149149

150-
* :class:`Extension` from :mod:`distutils.extension`
150+
* :class:`~distutils.extension.Extension` from :mod:`distutils.extension`
151151

152-
* :class:`Command` from :mod:`distutils.cmd`
152+
* :class:`~distutils.cmd.Command` from :mod:`distutils.cmd`
153153

154-
* :class:`Distribution` from :mod:`distutils.dist`
154+
* :class:`~distutils.dist.Distribution` from :mod:`distutils.dist`
155155

156156
A short description of each of these follows, but see the relevant module for
157157
the full reference.
@@ -1679,8 +1679,8 @@ lines, and joining lines with backslashes.
16791679
===================================================================
16801680

16811681
.. module:: distutils.cmd
1682-
:synopsis: This module provides the abstract base class Command. This class is subclassed
1683-
by the modules in the distutils.command subpackage.
1682+
:synopsis: This module provides the abstract base class Command. This class
1683+
is subclassed by the modules in the distutils.command subpackage.
16841684

16851685

16861686
This module supplies the abstract base class :class:`Command`.
@@ -1690,20 +1690,84 @@ This module supplies the abstract base class :class:`Command`.
16901690

16911691
Abstract base class for defining command classes, the "worker bees" of the
16921692
Distutils. A useful analogy for command classes is to think of them as
1693-
subroutines with local variables called *options*. The options are declared in
1694-
:meth:`initialize_options` and defined (given their final values) in
1695-
:meth:`finalize_options`, both of which must be defined by every command class.
1696-
The distinction between the two is necessary because option values might come
1697-
from the outside world (command line, config file, ...), and any options
1698-
dependent on other options must be computed after these outside influences have
1699-
been processed --- hence :meth:`finalize_options`. The body of the subroutine,
1700-
where it does all its work based on the values of its options, is the
1701-
:meth:`run` method, which must also be implemented by every command class.
1702-
1703-
The class constructor takes a single argument *dist*, a :class:`Distribution`
1693+
subroutines with local variables called *options*. The options are declared
1694+
in :meth:`initialize_options` and defined (given their final values) in
1695+
:meth:`finalize_options`, both of which must be defined by every command
1696+
class. The distinction between the two is necessary because option values
1697+
might come from the outside world (command line, config file, ...), and any
1698+
options dependent on other options must be computed after these outside
1699+
influences have been processed --- hence :meth:`finalize_options`. The body
1700+
of the subroutine, where it does all its work based on the values of its
1701+
options, is the :meth:`run` method, which must also be implemented by every
1702+
command class.
1703+
1704+
The class constructor takes a single argument *dist*, a :class:`Distribution`
17041705
instance.
17051706

17061707

1708+
Creating a new Distutils command
1709+
================================
1710+
1711+
This section outlines the steps to create a new Distutils command.
1712+
1713+
A new command lives in a module in the :mod:`distutils.command` package. There
1714+
is a sample template in that directory called :file:`command_template`. Copy
1715+
this file to a new module with the same name as the new command you're
1716+
implementing. This module should implement a class with the same name as the
1717+
module (and the command). So, for instance, to create the command
1718+
``peel_banana`` (so that users can run ``setup.py peel_banana``), you'd copy
1719+
:file:`command_template` to :file:`distutils/command/peel_banana.py`, then edit
1720+
it so that it's implementing the class :class:`peel_banana`, a subclass of
1721+
:class:`distutils.cmd.Command`.
1722+
1723+
Subclasses of :class:`Command` must define the following methods.
1724+
1725+
.. method:: Command.initialize_options()
1726+
1727+
Set default values for all the options that this command supports. Note that
1728+
these defaults may be overridden by other commands, by the setup script, by
1729+
config files, or by the command-line. Thus, this is not the place to code
1730+
dependencies between options; generally, :meth:`initialize_options`
1731+
implementations are just a bunch of ``self.foo = None`` assignments.
1732+
1733+
1734+
.. method:: Command.finalize_options()
1735+
1736+
Set final values for all the options that this command supports. This is
1737+
always called as late as possible, ie. after any option assignments from the
1738+
command-line or from other commands have been done. Thus, this is the place
1739+
to to code option dependencies: if *foo* depends on *bar*, then it is safe to
1740+
set *foo* from *bar* as long as *foo* still has the same value it was
1741+
assigned in :meth:`initialize_options`.
1742+
1743+
1744+
.. method:: Command.run()
1745+
1746+
A command's raison d'etre: carry out the action it exists to perform, controlled
1747+
by the options initialized in :meth:`initialize_options`, customized by other
1748+
commands, the setup script, the command-line, and config files, and finalized in
1749+
:meth:`finalize_options`. All terminal output and filesystem interaction should
1750+
be done by :meth:`run`.
1751+
1752+
1753+
.. attribute:: Command.sub_commands
1754+
1755+
*sub_commands* formalizes the notion of a "family" of commands,
1756+
e.g. ``install`` as the parent with sub-commands ``install_lib``,
1757+
``install_headers``, etc. The parent of a family of commands defines
1758+
*sub_commands* as a class attribute; it's a list of 2-tuples ``(command_name,
1759+
predicate)``, with *command_name* a string and *predicate* a function, a
1760+
string or ``None``. *predicate* is a method of the parent command that
1761+
determines whether the corresponding command is applicable in the current
1762+
situation. (E.g. we ``install_headers`` is only applicable if we have any C
1763+
header files to install.) If *predicate* is ``None``, that command is always
1764+
applicable.
1765+
1766+
*sub_commands* is usually defined at the *end* of a class, because
1767+
predicates can be methods of the class, so they must already have been
1768+
defined. The canonical example is the :command:`install` command.
1769+
1770+
17071771
:mod:`distutils.command` --- Individual Distutils commands
17081772
==========================================================
17091773

@@ -1942,63 +2006,3 @@ The ``register`` command registers the package with the Python Package Index.
19422006
This is described in more detail in :pep:`301`.
19432007

19442008
.. % todo
1945-
1946-
1947-
Creating a new Distutils command
1948-
================================
1949-
1950-
This section outlines the steps to create a new Distutils command.
1951-
1952-
A new command lives in a module in the :mod:`distutils.command` package. There
1953-
is a sample template in that directory called :file:`command_template`. Copy
1954-
this file to a new module with the same name as the new command you're
1955-
implementing. This module should implement a class with the same name as the
1956-
module (and the command). So, for instance, to create the command
1957-
``peel_banana`` (so that users can run ``setup.py peel_banana``), you'd copy
1958-
:file:`command_template` to :file:`distutils/command/peel_banana.py`, then edit
1959-
it so that it's implementing the class :class:`peel_banana`, a subclass of
1960-
:class:`distutils.cmd.Command`.
1961-
1962-
Subclasses of :class:`Command` must define the following methods.
1963-
1964-
1965-
.. method:: Command.initialize_options()
1966-
1967-
Set default values for all the options that this command supports. Note that
1968-
these defaults may be overridden by other commands, by the setup script, by
1969-
config files, or by the command-line. Thus, this is not the place to code
1970-
dependencies between options; generally, :meth:`initialize_options`
1971-
implementations are just a bunch of ``self.foo = None`` assignments.
1972-
1973-
1974-
.. method:: Command.finalize_options()
1975-
1976-
Set final values for all the options that this command supports. This is
1977-
always called as late as possible, ie. after any option assignments from the
1978-
command-line or from other commands have been done. Thus, this is the place
1979-
to to code option dependencies: if *foo* depends on *bar*, then it is safe to
1980-
set *foo* from *bar* as long as *foo* still has the same value it was
1981-
assigned in :meth:`initialize_options`.
1982-
1983-
1984-
.. method:: Command.run()
1985-
1986-
A command's raison d'etre: carry out the action it exists to perform, controlled
1987-
by the options initialized in :meth:`initialize_options`, customized by other
1988-
commands, the setup script, the command-line, and config files, and finalized in
1989-
:meth:`finalize_options`. All terminal output and filesystem interaction should
1990-
be done by :meth:`run`.
1991-
1992-
*sub_commands* formalizes the notion of a "family" of commands, eg. ``install``
1993-
as the parent with sub-commands ``install_lib``, ``install_headers``, etc. The
1994-
parent of a family of commands defines *sub_commands* as a class attribute; it's
1995-
a list of 2-tuples ``(command_name, predicate)``, with *command_name* a string
1996-
and *predicate* a function, a string or None. *predicate* is a method of
1997-
the parent command that determines whether the corresponding command is
1998-
applicable in the current situation. (Eg. we ``install_headers`` is only
1999-
applicable if we have any C header files to install.) If *predicate* is None,
2000-
that command is always applicable.
2001-
2002-
*sub_commands* is usually defined at the \*end\* of a class, because predicates
2003-
can be methods of the class, so they must already have been defined. The
2004-
canonical example is the :command:`install` command.

Doc/distutils/extending.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -15,8 +15,8 @@ want to modify existing commands; many simply add a few file extensions that
1515
should be copied into packages in addition to :file:`.py` files as a
1616
convenience.
1717

18-
Most distutils command implementations are subclasses of the :class:`Command`
19-
class from :mod:`distutils.cmd`. New commands may directly inherit from
18+
Most distutils command implementations are subclasses of the
19+
:class:`distutils.cmd.Command` class. New commands may directly inherit from
2020
:class:`Command`, while replacements often derive from :class:`Command`
2121
indirectly, directly subclassing the command they are replacing. Commands are
2222
required to derive from :class:`Command`.

0 commit comments

Comments
 (0)