A bundle of wording improvements, corrections, clarifications, updates,

and so forth.

1 files changed, 77 insertions, 68 deletions

diff --git a/Doc/dist/dist.tex b/Doc/dist/dist.tex
index 8f17115..e7d9f44 100644
--- a/Doc/dist/dist.tex
+++ b/Doc/dist/dist.tex
@@ -21,16 +21,16 @@ In the past, Python module developers have not had much infrastructure
 support for distributing modules, nor have Python users had much support
 for installing and maintaining third-party modules.  With the
 introduction of the Python Distribution Utilities (Distutils for short)
-in Python 2.0, this situation should start to improve.
+in Python 1.6, this situation should start to improve.
 
 This document only covers using the Distutils to distribute your Python
-modules.  Using the Distutils does not tie you to Python 2.0, though:
-the Distutils work just fine with Python 1.5, and it is reasonable (and
-expected to become commonplace) to expect users of Python 1.5 to
+modules.  Using the Distutils does not tie you to Python 1.6, though:
+the Distutils work just fine with Python 1.5.2, and it is reasonable
+(and expected to become commonplace) to expect users of Python 1.5.2 to
 download and install the Distutils separately before they can install
-your modules.  Python 2.0 users, of course, won't have to add anything
-to their Python installation in order to use the Distutils to install
-third-party modules.
+your modules.  Python 1.6 (or later) users, of course, won't have to add
+anything to their Python installation in order to use the Distutils to
+install third-party modules.
 
 This document concentrates on the role of developer/distributor: if
 you're looking for information on installing Python modules, you
@@ -68,9 +68,10 @@ without having to run a single setup script or compile a line of code.
 \label{simple-example}
 
 The setup script is usually quite simple, although since it's written in
-Python, there are no arbitrary limits to what you can do.  If all you
-want to do is distribute a module called \module{foo}, contained in a
-file \file{foo.py}, then your setup script can be as little as this:
+Python, there are no arbitrary limits to what you can do with it.  If
+all you want to do is distribute a module called \module{foo}, contained
+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",
@@ -118,7 +119,6 @@ almost exclusively for module developers, while \command{install} is
 more often for installers (although most developers will want to install
 their own code occasionally).
 
-\XXX{only partially implemented}%
 If you want to make things really easy for your users, you can create
 one or more built distributions for them.  For instance, if you are
 running on a Windows machine, and want to make things easy for other
@@ -128,9 +128,10 @@ appropriate type of built distribution for this platform) with the
 \begin{verbatim}
 python setup.py bdist_wininst
 \end{verbatim}
-will create an executable installer, \file{Foo-1\_0.exe}, in the current
-directory.
+will create an executable installer, \file{Foo-1.0.win32.exe}, in the
+current directory.
 
+\XXX{not implemented yet}
 (Another way to create executable installers for Windows is with the
 \command{bdist\_wise} command, which uses Wise---the commercial
 installer-generator used to create Python's own installer---to create
@@ -142,11 +143,21 @@ medium-sized module collections.  You'll need to have version XXX of
 Wise installed on your system for the \command{bdist\_wise} command to
 work; it's available from \url{http://foo/bar/baz}.)
 
-Other \command{bdist} commands exist for other platforms: for example,
-\command{bdist\_rpm} for RPM-based Linux systems, (\command{bdist\_deb})
-for Debian-based Linux systems, and so forth.  See
-section~\ref{bdist-cmds} for details on all the \command{bdist}
-commands.
+Currently (Distutils 0.9.1), the are only other useful built
+distribution format is RPM, implemented by the \command{bdist\_rpm}
+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.)
+
+You can find out what distribution formats are available at any time by
+running
+\begin{verbatim}
+python setup.py bdist --help-formats
+\end{verbatim}
 
 
 \subsection{General Python terminology}
@@ -158,9 +169,8 @@ that everyone is operating from a common starting point, we offer the
 following glossary of common Python terms:
 \begin{description}
 \item[module] the basic unit of code reusability in Python: a block of
-  code imported by some other code.  There are three types of modules
-  that concern us here: pure Python modules, extension modules, and
-  packages.
+  code imported by some other code.  Three types of modules concern us
+  here: pure Python modules, extension modules, and packages.
 \item[pure Python module] a module written in Python and contained in a
   single \file{.py} file (and possibly associated \file{.pyc} and/or
   \file{.pyo} files).  Sometimes referred to as a ``pure module.''
@@ -224,10 +234,10 @@ supplied as keyword arguments to \function{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 Distutils are included with Python 2.0, they also have an
-independent existence so that Python 1.5 users can use them to install
-other module distributions.  The Distutils' own setup script is used to
-install the package into Python 1.5.)
+although the Distutils are included with Python 1.6 and later, they also
+have an independent existence so that Python 1.5.2 users can use them to
+install other module distributions.  The Distutils' own setup script,
+shown here, is used to install the package into Python 1.5.2.)
 
 \begin{verbatim}
 #!/usr/bin/env python
@@ -236,7 +246,7 @@ from distutils.core import setup
 
 setup (name = "Distutils",
        version = "1.0",
-       description = "Python Module Distribution Utilities",
+       description = "Python Distribution Utilities",
        author = "Greg Ward",
        author_email = "gward@python.net",
        url = "http://www.python.org/sigs/distutils-sig/",
@@ -284,17 +294,17 @@ package anyways.)
 If you use a different convention to lay out your source directory,
 that's no problem: you just have to supply the \option{package\_dir}
 option to tell the Distutils about your convention.  For example, say
-you keep all Python source under \file{lib}, so that modules not in any
-package are right in \file{lib}, modules in the \module{foo} package
-are in \file{lib/foo}, and so forth.  Then you would put
+you keep all Python source under \file{lib}, so that modules in the
+``root package'' (i.e., not in any package at all) are right in
+\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,'' i.e. no
-package at all.  The values are directory names relative to your
-distribution root.)  In this case, when you say
-\code{packages = ['foo']}, you are promising that the file
+and an empty package name stands for the root package.  The values are
+directory names relative to your distribution root.)  In this case, when
+you say \code{packages = ['foo']}, you are promising that the file
 \file{lib/foo/\_\_init\_\_.py} exists.
 
 Another possible convention is to put the \module{foo} package right in 
@@ -337,15 +347,11 @@ And again, you can override the package/directory layout using the
 \subsection{Describing extension modules}
 \label{sec:describing-extensions}
 
-\XXX{be sure to describe the whole \code{build\_info} dict, including
-  \code{extra\_compile\_args} and \code{extra\_link\_args}}
 
 
 \section{Writing the Setup Configuration File}
 \label{setup-config}
 
-\XXX{not implemented yet!}
-
 Often, it's not possible to write down everything needed to build a
 distribution \emph{a priori}.  You need to get some information from the
 user, or from the user's system, in order to proceed.  For example, you
@@ -491,8 +497,9 @@ follows:
 \begin{itemize}
 \item if the manifest file, \file{MANIFEST} doesn't exist, read
   \file{MANIFEST.in} and create the manifest
-\item if \file{MANIFEST.in} is more recent than \file{MANIFEST},
-  recreate \file{MANIFEST} by reading \file{MANIFEST.in}
+\item if either \file{MANIFEST.in} or the setup script (\file{setup.py})
+  are more recent than \file{MANIFEST}, recreate \file{MANIFEST} by
+  reading \file{MANIFEST.in}
 \item use the list of files now in \file{MANIFEST} (either just
   generated or read in) to create the source distribution archive(s)
 \end{itemize}
@@ -505,8 +512,6 @@ manifest:
 \begin{verbatim}
 python setup.py sdist --force-manifest
 \end{verbatim}
-\XXX{this is stupid, but is there a better way to do it without
-  reprocessing MANIFEST.in every single bloody time?}
 
 Or, you might just want to (re)generate the manifest, but not create a
 source distribution:
@@ -562,54 +567,57 @@ python setup.py bdist
 then the Distutils builds my module distribution (the Distutils itself
 in this case), does a ``fake'' installation (also in the \file{build}
 directory), and creates the default type of built distribution for my
-platform.  In Distutils 0.8, only two types of built distribution are
-supported: \code{gztar} (default on non-Linux Unix) and \code{zip}
-(default on Windows).  Thus, the above command on a Unix system creates
-\file{Distutils-0.8.built-posix.tar.gz}; unpacking this tarball from
-Python's \filevar{prefix} directory installs the Distutils just as
-though you had downloaded the source distribution and run \code{python
-  setup.py install}.  Obviously, for pure Python distributions, this
-isn't a huge win---but for non-pure distributions, which include
-extensions that would need to be compiled, it can mean the difference
-between someone being able to use your extensions or not.
+platform.  Currently, the default format for built distributions is a
+``dumb'' archive---tarball on Unix, ZIP file on Windows.  (These are
+called ``dumb'' built distributions, because they must be unpacked in a
+specific location to work.)
+
+Thus, the above command on a Unix system creates
+\file{Distutils-0.9.1.\filevar{plat}.tar.gz}; unpacking this tarball
+from the root of the filesystemq installs the Distutils just as though
+you had downloaded the source distribution and run \code{python setup.py
+  install}.  (Assuming that the target system has their Python
+installation laid out the same as you do---another reason these are
+called ``dumb'' distributions.)  Obviously, for pure Python
+distributions, this isn't a huge win---but for non-pure distributions,
+which include extensions that would need to be compiled, it can mean the
+difference between someone being able to use your extensions or not.
 
 \XXX{filenames are inaccurate here!}
 
 The \command{bdist} command has a \longprogramopt{format} option,
-similar to the \command{sdist} command, that you can use to select which
-formats to generate: for example,
+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.built-posix.tar.gz}---again, this archive would be
-unpacked from Python's \filevar{prefix} directory to install the
-Distutils.
+\file{Distutils-0.8.\filevar{plat}.zip}---again, this archive would be
+unpacked from the root directory to install the Distutils.
 
 The available formats for built distributions are:
 \begin{tableiii}{l|l|c}{code}%
   {Format}{Description}{Notes}
-  \lineiii{zip}{zip file (\file{.zip})}{(1)}
-  \lineiii{gztar}{gzipped tar file (\file{.tar.gz})}{(2)}
+  \lineiii{zip}{zip file (\file{.zip})}{}
+  \lineiii{gztar}{gzipped tar file (\file{.tar.gz})}{(1)}
   \lineiii{ztar}{compressed tar file (\file{.tar.Z})}{}
   \lineiii{tar}{tar file (\file{.tar})}{}
-  \lineiii{rpm}{RPM}{(3)}
-  \lineiii{srpm}{source RPM}{}
-  \lineiii{wise}{Wise installer for Windows}{}
+  \lineiii{rpm}{RPM}{}
+  \lineiii{srpm}{source RPM}{\XXX{to do!}}
+  \lineiii{wininst}{self-extracting ZIP file for Windows}{(2)}
+  %\lineiii{wise}{Wise installer for Windows}{(3)}
 \end{tableiii}
 
 \noindent Notes:
 \begin{description}
-\item[(1)] default on Windows
-\item[(2)] default on Unix
-\item[(3)] not implemented yet; will be default on RPM-based Linux
-  systems
-\item[(5)] not implemented yet; will be default on Windows
+\item[(1)] default on Unix
+\item[(2)] default on Windows \XXX{to-do!}
+%\item[(3)] not implemented yet
 \end{description}
 
 You don't have to use the \command{bdist} command with the
 \longprogramopt{formats} option; you can also use the command that
-directly implements the format you're interested in.  Many of these
+directly implements the format you're interested in.  Some of these
 \command{bdist} ``sub-commands'' actually generate several similar
 formats; for instance, the \command{bdist\_dumb} command generates all
 the ``dumb'' archive formats (\code{tar}, \code{ztar}, \code{gztar}, and
@@ -620,7 +628,8 @@ each, are:
   {Command}{Formats}
   \lineii{bdist\_dumb}{tar, ztar, gztar, zip}
   \lineii{bdist\_rpm}{rpm, srpm}
-  \lineii{bdist\_wise}{wise}
+  \lineii{bdist\_wininst}{wininst}
+  %\lineii{bdist\_wise}{wise}
 \end{tableii}
 
 \section{Examples}