[Python-checkins] CVS: python/dist/src/Doc/dist dist.tex,1.32,1.33
Fred L. Drake
fdrake@users.sourceforge.net
2001年3月01日 10:35:46 -0800
Update of /cvsroot/python/python/dist/src/Doc/dist
In directory usw-pr-cvs1:/tmp/cvs-serv18233/dist
Modified Files:
dist.tex
Log Message:
Comment out section titles for sections that have not been written yet;
there is no need to clutter a reader's life with those useless things.
Make the snippets of Python code conform to the standard style.
Suppress the "Contents" page for HTML; it is not needed for small documents
in the online environment since LaTeX2HTML generates lots of tables of links
anyway.
Various markup consistency nits.
Index: dist.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/dist/dist.tex,v
retrieving revision 1.32
retrieving revision 1.33
diff -C2 -r1.32 -r1.33
*** dist.tex 2001年02月19日 19:14:50 1.32
--- dist.tex 2001年03月01日 18:35:43 1.33
***************
*** 23,28 ****
--- 23,34 ----
\end{abstract}
+ % The ugly "%begin{latexonly}" pseudo-environment supresses the table
+ % of contents for HTML generation.
+ %
+ %begin{latexonly}
\tableofcontents
+ %end{latexonly}
+
\section{Introduction}
\label{intro}
***************
*** 89,97 ****
in a file \file{foo.py}, then your setup script can be as little as
this:
\begin{verbatim}
from distutils.core import setup
! setup (name = "foo",
! version = "1.0",
! py_modules = ["foo"])
\end{verbatim}
--- 95,104 ----
in a file \file{foo.py}, then your setup script can be as little as
this:
+
\begin{verbatim}
from distutils.core import setup
! setup(name="foo",
! version="1.0",
! py_modules=["foo"])
\end{verbatim}
***************
*** 112,118 ****
--- 119,127 ----
To create a source distribution for this module, you would create a
setup script, \file{setup.py}, containing the above code, and run:
+
\begin{verbatim}
python setup.py sdist
\end{verbatim}
+
which will create an archive file (e.g., tarball on \UNIX, ZIP file on
Windows) containing your setup script, \file{setup.py}, and your module,
***************
*** 123,129 ****
--- 132,140 ----
to do is download \file{Foo-1.0.tar.gz} (or \file{.zip}), unpack it,
and---from the \file{Foo-1.0} directory---run
+
\begin{verbatim}
python setup.py install
\end{verbatim}
+
which will ultimately copy \file{foo.py} to the appropriate directory
for third-party modules in their Python installation.
***************
*** 143,149 ****
--- 154,162 ----
appropriate type of built distribution for this platform) with the
\command{bdist\_wininst} command. For example:
+
\begin{verbatim}
python setup.py bdist_wininst
\end{verbatim}
+
will create an executable installer, \file{Foo-1.0.win32.exe}, in the
current directory.
***************
*** 153,159 ****
--- 166,174 ----
command. For example, the following command will create an RPM file
called \file{Foo-1.0.noarch.rpm}:
+
\begin{verbatim}
python setup.py bdist_rpm
\end{verbatim}
+
(This uses the \command{rpm} command, so has to be run on an RPM-based
system such as Red Hat Linux, SuSE Linux, or Mandrake Linux.)
***************
*** 161,164 ****
--- 176,180 ----
You can find out what distribution formats are available at any time by
running
+
\begin{verbatim}
python setup.py bdist --help-formats
***************
*** 250,263 ****
from distutils.core import setup
! setup (name = "Distutils",
! version = "1.0",
! description = "Python Distribution Utilities",
! author = "Greg Ward",
! author_email = "gward@python.net",
! url = "http://www.python.org/sigs/distutils-sig/",
!
! packages = ['distutils', 'distutils.command'],
! )
\end{verbatim}
There are only two differences between this and the trivial one-file
distribution presented in section~\ref{simple-example}: more
--- 266,279 ----
from distutils.core import setup
! setup(name="Distutils",
! version="1.0",
! description="Python Distribution Utilities",
! author="Greg Ward",
! author_email="gward@python.net",
! url="http://www.python.org/sigs/distutils-sig/",
! packages=['distutils', 'distutils.command'],
! )
\end{verbatim}
+
There are only two differences between this and the trivial one-file
distribution presented in section~\ref{simple-example}: more
***************
*** 283,286 ****
--- 299,303 ----
or os.listdir to specify files, you should be careful to write portable
code instead of hardcoding path separators:
+
\begin{verbatim}
glob.glob(os.path.join('mydir', 'subdir', '*.html'))
***************
*** 312,318 ****
--- 329,337 ----
\file{lib}, modules in the \module{foo} package are in \file{lib/foo},
and so forth. Then you would put
+
\begin{verbatim}
package_dir = {'': 'lib'}
\end{verbatim}
+
in your setup script. (The keys to this dictionary are package names,
and an empty package name stands for the root package. The values are
***************
*** 324,330 ****
--- 343,351 ----
\file{lib}, the \module{foo.bar} package in \file{lib/bar}, etc. This
would be written in the setup script as
+
\begin{verbatim}
package_dir = {'foo': 'lib'}
\end{verbatim}
+
A \code{\var{package}: \var{dir}} entry in the \option{package\_dir}
dictionary implicitly applies to all packages below \var{package}, so
***************
*** 347,353 ****
--- 368,376 ----
simplest case was shown in section~\ref{simple-example}; here is a
slightly more involved example:
+
\begin{verbatim}
py_modules = ['mod1', 'pkg.mod2']
\end{verbatim}
+
This describes two modules, one of them in the ``root'' package, the
other in the \module{pkg} package. Again, the default package/directory
***************
*** 376,390 ****
additional instructions to the compiler/linker are needed, describing
this extension is quite simple:
\begin{verbatim}
Extension("foo", ["foo.c"])
\end{verbatim}
The \class{Extension} class can be imported from
\module{distutils.core}, along with \function{setup()}. Thus, the setup
script for a module distribution that contains only this one extension
and nothing else might be:
\begin{verbatim}
from distutils.core import setup, Extension
! setup(name = "foo", version = "1.0",
! ext_modules = [Extension("foo", ["foo.c"])])
\end{verbatim}
--- 399,416 ----
additional instructions to the compiler/linker are needed, describing
this extension is quite simple:
+
\begin{verbatim}
Extension("foo", ["foo.c"])
\end{verbatim}
+
The \class{Extension} class can be imported from
\module{distutils.core}, along with \function{setup()}. Thus, the setup
script for a module distribution that contains only this one extension
and nothing else might be:
+
\begin{verbatim}
from distutils.core import setup, Extension
! setup(name="foo", version="1.0",
! ext_modules=[Extension("foo", ["foo.c"])])
\end{verbatim}
***************
*** 399,409 ****
--- 425,439 ----
The first argument to the \class{Extension} constructor is always the
name of the extension, including any package names. For example,
+
\begin{verbatim}
Extension("foo", ["src/foo1.c", "src/foo2.c"])
\end{verbatim}
+
describes an extension that lives in the root package, while
+
\begin{verbatim}
Extension("pkg.foo", ["src/foo1.c", "src/foo2.c"])
\end{verbatim}
+
describes the same extension in the \module{pkg} package. The source
files and resulting object code are identical in both cases; the only
***************
*** 414,424 ****
the same base package), use the \option{ext\_package} keyword argument
to \function{setup()}. For example,
\begin{verbatim}
setup(...
! ext_package = "pkg",
! ext_modules = [Extension("foo", ["foo.c"]),
! Extension("subpkg.bar", ["bar.c"])]
)
\end{verbatim}
will compile \file{foo.c} to the extension \module{pkg.foo}, and
\file{bar.c} to \module{pkg.subpkg.bar}.
--- 444,456 ----
the same base package), use the \option{ext\_package} keyword argument
to \function{setup()}. For example,
+
\begin{verbatim}
setup(...
! ext_package="pkg",
! ext_modules=[Extension("foo", ["foo.c"]),
! Extension("subpkg.bar", ["bar.c"])]
)
\end{verbatim}
+
will compile \file{foo.c} to the extension \module{pkg.foo}, and
\file{bar.c} to \module{pkg.subpkg.bar}.
***************
*** 459,462 ****
--- 491,495 ----
\file{include} directory under your distribution root, use the
\code{include\_dirs} option:
+
\begin{verbatim}
Extension("foo", ["foo.c"], include_dirs=["include"])
***************
*** 466,472 ****
--- 499,507 ----
extension will only be built on \UNIX{} systems with X11R6 installed to
\file{/usr}, you can get away with
+
\begin{verbatim}
Extension("foo", ["foo.c"], include_dirs=["/usr/include/X11"])
\end{verbatim}
+
You should avoid this sort of non-portable usage if you plan to
distribute your code: it's probably better to write your code to include
***************
*** 486,489 ****
--- 521,525 ----
though, you can find that directory using the Distutils
\module{sysconfig} module:
+
\begin{verbatim}
from distutils.sysconfig import get_python_inc
***************
*** 492,495 ****
--- 528,532 ----
Extension(..., include_dirs=[incdir]))
\end{verbatim}
+
Even though this is quite portable---it will work on any Python
installation, regardless of platform---it's probably easier to just
***************
*** 507,510 ****
--- 544,548 ----
For example:
+
\begin{verbatim}
Extension(...,
***************
*** 513,517 ****
--- 551,557 ----
undef_macros=['HAVE_FOO', 'HAVE_BAR'])
\end{verbatim}
+
is the equivalent of having this at the top of every C source file:
+
\begin{verbatim}
#define NDEBUG 1
***************
*** 533,536 ****
--- 573,577 ----
For example, if you need to link against libraries known to be in the
standard library search path on target systems
+
\begin{verbatim}
Extension(...,
***************
*** 540,543 ****
--- 581,585 ----
If you need to link with libraries in a non-standard location, you'll
have to include the location in \code{library\_dirs}:
+
\begin{verbatim}
Extension(...,
***************
*** 545,548 ****
--- 587,591 ----
libraries=["X11", "Xt"])
\end{verbatim}
+
(Again, this sort of non-portable construct should be avoided if you
intend to distribute your code.)
***************
*** 585,588 ****
--- 628,632 ----
\subsection{Listing additional files}
+
The \option{data\_files} option can be used to specify additional
files needed by the module distribution: configuration files,
***************
*** 591,594 ****
--- 635,639 ----
\option{data\_files} specify a sequence of \code{(directory, files)}
pairs in the following way:
+
\begin{verbatim}
setup(...
***************
*** 626,632 ****
or stable enough yet for real-world use.)
- \XXX{should reference description of distutils config files in
- ``Installing'' manual here}
-
The setup configuration file is a useful middle-ground between the setup
script---which, ideally, would be opaque to installers\footnote{This
--- 671,674 ----
***************
*** 648,651 ****
--- 690,694 ----
The basic syntax of the configuration file is simple:
+
\begin{verbatim}
[command]
***************
*** 653,656 ****
--- 696,700 ----
...
\end{verbatim}
+
where \var{command} is one of the Distutils commands (e.g.
\command{build\_py}, \command{install}), and \var{option} is one of the
***************
*** 663,666 ****
--- 707,711 ----
You can find out the list of options supported by a particular command
with the universal \longprogramopt{help} option, e.g.
+
\begin{verbatim}
> python setup.py --help build_ext
***************
*** 676,679 ****
--- 721,725 ----
[...]
\end{verbatim}
+
Or consult section \ref{reference} of this document (the command
reference).
***************
*** 688,702 ****
--- 734,752 ----
\module{pkg.mod1} and \module{pkg.mod2}. You can always use the
\longprogramopt{inplace} option on the command-line to ensure this:
+
\begin{verbatim}
python setup.py build_ext --inplace
\end{verbatim}
+
But this requires that you always specify the \command{build\_ext}
command explicitly, and remember to provide \longprogramopt{inplace}.
An easier way is to ``set and forget'' this option, by encoding it in
\file{setup.cfg}, the configuration file for this distribution:
+
\begin{verbatim}
[build_ext]
inplace=1
\end{verbatim}
+
This will affect all builds of this module distribution, whether or not
you explcitly specify \command{build\_ext}. If you include
***************
*** 718,721 ****
--- 768,772 ----
command-line for every run. Hence, here is a snippet from the
Distutils' own \file{setup.cfg}:
+
\begin{verbatim}
[bdist_rpm]
***************
*** 728,735 ****
--- 779,794 ----
examples/
\end{verbatim}
+
Note that the \option{doc\_files} option is simply a
whitespace-separated string split across multiple lines for readability.
+ \begin{seealso}
+ \seetitle[../inst/config-syntax.html]{Installing Python
+ Modules}{More information on the configuration files is
+ available in the manual for system administrators.}
+ \end{seealso}
+
+
\section{Creating a Source Distribution}
\label{source-dist}
***************
*** 738,744 ****
--- 797,805 ----
\command{sdist} command to create a source distribution. In the
simplest case,
+
\begin{verbatim}
python setup.py sdist
\end{verbatim}
+
(assuming you haven't specified any \command{sdist} options in the setup
script or config file), \command{sdist} creates the archive of the
***************
*** 749,755 ****
--- 810,818 ----
You can specify as many formats as you like using the
\longprogramopt{formats} option, for example:
+
\begin{verbatim}
python setup.py sdist --formats=gztar,zip
\end{verbatim}
+
to create a gzipped tarball and a zip file. The available formats are:
\begin{tableiii}{l|l|c}{code}%
***************
*** 811,814 ****
--- 874,878 ----
distribution. For an example, again we turn to the Distutils' own
manifest template:
+
\begin{verbatim}
include *.txt
***************
*** 816,819 ****
--- 880,884 ----
prune examples/sample?/build
\end{verbatim}
+
The meanings should be fairly clear: include all files in the
distribution root matching \code{*.txt}, all files anywhere under the
***************
*** 906,909 ****
--- 971,975 ----
existing pattern in the manifest template, you should regenerate the
manifest:
+
\begin{verbatim}
python setup.py sdist --force-manifest
***************
*** 912,918 ****
--- 978,986 ----
Or, you might just want to (re)generate the manifest, but not create a
source distribution:
+
\begin{verbatim}
python setup.py sdist --manifest-only
\end{verbatim}
+
\longprogramopt{manifest-only} implies \longprogramopt{force-manifest}.
\programopt{-o} is a shortcut for \longprogramopt{manifest-only}, and
***************
*** 954,960 ****
--- 1022,1030 ----
As a simple example, if I run the following command in the Distutils
source tree:
+
\begin{verbatim}
python setup.py bdist
\end{verbatim}
+
then the Distutils builds my module distribution (the Distutils itself
in this case), does a ``fake'' installation (also in the \file{build}
***************
*** 984,990 ****
--- 1054,1062 ----
similar to the \command{sdist} command, which you can use to select the
types of built distribution to generate: for example,
+
\begin{verbatim}
python setup.py bdist --format=zip
\end{verbatim}
+
would, when run on a \UNIX{} system, create
\file{Distutils-0.8.\filevar{plat}.zip}---again, this archive would be
***************
*** 1055,1069 ****
--- 1127,1146 ----
The usual way to create an RPM of your module distribution is to run the
\command{bdist\_rpm} command:
+
\begin{verbatim}
python setup.py bdist_rpm
\end{verbatim}
+
or the \command{bdist} command with the \longprogramopt{format} option:
+
\begin{verbatim}
python setup.py bdist --formats=rpm
\end{verbatim}
+
The former allows you to specify RPM-specific options; the latter allows
you to easily specify multiple formats in one run. If you need to do
both, you can explicitly specify multiple \command{bdist\_*} commands
and their options:
+
\begin{verbatim}
python setup.py bdist_rpm --packager="John Doe <jdoe@python.net>" \
***************
*** 1144,1147 ****
--- 1221,1225 ----
\longprogramopt{spec-only}, this gives you an opportunity to customize
the \file{.spec} file manually:
+
\begin{verbatim}
> python setup.py bdist_rpm --spec-only
***************
*** 1149,1152 ****
--- 1227,1231 ----
> python setup.py bdist_rpm --spec-file=dist/FooBar-1.0.spec
\end{verbatim}
+
(Although a better way to do this is probably to override the standard
\command{bdist\_rpm} command with one that writes whatever else you want
***************
*** 1166,1173 ****
--- 1245,1255 ----
Since the meta-data is taken from the setup script, creating
Windows installers is usually as easy as running:
+
\begin{verbatim}
python setup.py bdist_wininst
\end{verbatim}
+
or the \command{bdist} command with the \longprogramopt{format} option:
+
\begin{verbatim}
python setup.py bdist --formats=wininst
***************
*** 1191,1230 ****
the \longprogramopt{no-target-optimize} option.
! \section{Examples}
! \label{examples}
! \subsection{Pure Python distribution (by module)}
! \label{pure-mod}
! \subsection{Pure Python distribution (by package)}
! \label{pure-pkg}
! \subsection{Single extension module}
! \label{single-ext}
! \subsection{Multiple extension modules}
! \label{multiple-ext}
! \subsection{Putting it all together}
! \section{Extending the Distutils}
! \label{extending}
! \subsection{Extending existing commands}
! \label{extend-existing}
! \subsection{Writing new commands}
! \label{new-commands}
! \XXX{Would an uninstall command be a good example here?}
--- 1273,1312 ----
the \longprogramopt{no-target-optimize} option.
! %\section{Examples}
! %\label{examples}
! %\subsection{Pure Python distribution (by module)}
! %\label{pure-mod}
! %\subsection{Pure Python distribution (by package)}
! %\label{pure-pkg}
! %\subsection{Single extension module}
! %\label{single-ext}
! %\subsection{Multiple extension modules}
! %\label{multiple-ext}
! %\subsection{Putting it all together}
! %\section{Extending the Distutils}
! %\label{extending}
! %\subsection{Extending existing commands}
! %\label{extend-existing}
! %\subsection{Writing new commands}
! %\label{new-commands}
! %\XXX{Would an uninstall command be a good example here?}
***************
*** 1234,1251 ****
! \subsection{Building modules: the \protect\command{build} command family}
! \label{build-cmds}
! \subsubsection{\protect\command{build}}
! \label{build-cmd}
! \subsubsection{\protect\command{build\_py}}
! \label{build-py-cmd}
! \subsubsection{\protect\command{build\_ext}}
! \label{build-ext-cmd}
! \subsubsection{\protect\command{build\_clib}}
! \label{build-clib-cmd}
--- 1316,1333 ----
! %\subsection{Building modules: the \protect\command{build} command family}
! %\label{build-cmds}
! %\subsubsection{\protect\command{build}}
! %\label{build-cmd}
! %\subsubsection{\protect\command{build\_py}}
! %\label{build-py-cmd}
! %\subsubsection{\protect\command{build\_ext}}
! %\label{build-ext-cmd}
! %\subsubsection{\protect\command{build\_clib}}
! %\label{build-clib-cmd}
***************
*** 1258,1263 ****
\command{install\_scripts}.
! \subsubsection{\protect\command{install\_lib}}
! \label{install-lib-cmd}
\subsubsection{\protect\command{install\_data}}
--- 1340,1345 ----
\command{install\_scripts}.
! %\subsubsection{\protect\command{install\_lib}}
! %\label{install-lib-cmd}
\subsubsection{\protect\command{install\_data}}
***************
*** 1270,1275 ****
! \subsection{Cleaning up: the \protect\command{clean} command}
! \label{clean-cmd}
--- 1352,1357 ----
! %\subsection{Cleaning up: the \protect\command{clean} command}
! %\label{clean-cmd}
***************
*** 1310,1332 ****
\XXX{Windows and MacOS support not there yet}
-
- \subsection{Creating a ``built'' distribution: the
- \protect\command{bdist} command family}
- \label{bdist-cmds}
-
-
- \subsubsection{\protect\command{blib}}
-
- \subsubsection{\protect\command{blib\_dumb}}
-
- \subsubsection{\protect\command{blib\_rpm}}
-
- \subsubsection{\protect\command{blib\_wise}}
--- 1392,1408 ----
\XXX{Windows and MacOS support not there yet}
+ %\subsection{Creating a built distribution: the
+ % \protect\command{bdist} command family}
+ %\label{bdist-cmds}
+ %\subsubsection{\protect\command{blib}}
+ %\subsubsection{\protect\command{blib\_dumb}}
+ %\subsubsection{\protect\command{blib\_rpm}}
+ %\subsubsection{\protect\command{blib\_wise}}