]> granicus.if.org Git - python/commitdiff
Fixed a grab-bag of typos spotted by Detlef Lannert.
authorGreg Ward <gward@python.net>
Sat, 24 Jun 2000 01:33:16 +0000 (01:33 +0000)
committerGreg Ward <gward@python.net>
Sat, 24 Jun 2000 01:33:16 +0000 (01:33 +0000)
Doc/dist/dist.tex
Doc/inst/inst.tex

index 60a42d18b5e8ce6af0136bdbe88ef8d2e1188980..ef4e32e8062456d2dc06c4bff5ad90f4f1a71a55 100644 (file)
@@ -55,13 +55,12 @@ Each of these tasks is covered in this document.
 Not all module developers have access to a multitude of platforms, so
 it's not always feasible to expect them to create a multitude of built
 distributions.  It is hoped that a class of intermediaries, called
-\emph{packagers}, will arise to take address this need.  Packagers will
-take source distributions released by module developers, build them on
-one or more platforms, and release the resulting built distributions.
-Thus, users on the most popular platforms will be able to install most
-popular Python module distributions in the most natural way for their
-platform, without having to run a single setup script or compile a line
-of code.
+\emph{packagers}, will arise to address this need.  Packagers will take
+source distributions released by module developers, build them on one or
+more platforms, and release the resulting built distributions.  Thus,
+users on the most popular platforms will be able to install most popular
+Python module distributions in the most natural way for their platform,
+without having to run a single setup script or compile a line of code.
 
 
 \subsection{A simple example}
@@ -373,8 +372,8 @@ 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 the archive of the
+(assuming you haven't specified any \command{sdist} options in the setup
+script or config file), \command{sdist} creates the archive of the
 default format for the current platform.  The default formats are:
 \begin{tableii}{ll}{textrm}%
   {Platform}{Default archive format for source distributions}
@@ -539,7 +538,7 @@ distributions for every platform under the sun, so the Distutils is
 designed to enable module developers to concentrate on their
 specialty---writing code and creating source distributions---while an
 intermediary species of \emph{packager} springs up to turn source
-distributions into build distributions for as many platforms as there
+distributions into built distributions for as many platforms as there
 are packagers.
 
 Of course, the module developer could be his own packager; or the
index c7da3dd9aa071f9a8903fb18157114f21c0eec41..c4e67aff4a25af5fb7623bcb97d00a55d3f86143 100644 (file)
@@ -97,9 +97,9 @@ building and installing modules from standard source distributions.
 \label{new-standard}
 
 If you download a module source distribution, you can tell pretty
-quickly if was packaged and distributed in the standard way, i.e. using
-the Distutils.  First, the distribution's name and version number will
-be featured prominently in the name of the downloaded archive, e.g.
+quickly if it was packaged and distributed in the standard way, i.e.
+using the Distutils.  First, the distribution's name and version number
+will be featured prominently in the name of the downloaded archive, e.g.
 \file{foo-1.0.tar.gz} or \file{widget-0.9.7.zip}.  Next, the archive
 will unpack into a similarly-named directory: \file{foo-1.0} or
 \file{widget-0.9.7}.  Additionally, the distribution will contain a
@@ -126,7 +126,7 @@ really possible to write a general manual for installing Python modules
 that don't use the Distutils; the only truly general statement that can
 be made is, ``Read the module's own installation instructions.''
 
-However, if such instructions exists at all, they are often woefully
+However, if such instructions exist at all, they are often woefully
 inadequate and targeted at experienced Python developers.  Such users
 are already familiar with how the Python library is laid out on their
 platform, and know where to copy various files in order for Python to
@@ -421,7 +421,7 @@ Python installation).  If this sounds a trifle unusual, it is---that's
 why the ``home scheme'' comes first.  However, there are at least two
 known cases where the prefix scheme will be useful.
 
-First, consider that many Linux distribution put Python in \file{/usr},
+First, consider that many Linux distributions put Python in \file{/usr},
 rather than the more traditional \file{/usr/local}.  This is entirely
 appropriate, since in those cases Python is part of ``the system''
 rather than a local add-on.  However, if you are installing Python
@@ -558,7 +558,7 @@ As you might expect, you can override this directory with the
 sense to supply a relative path, which will be interpreted relative to
 the installation base directory (your home directory, in this case):
 \begin{verbatim}
-python setup.py install --home --install-scripts=scripts
+python setup.py install --home=~ --install-scripts=scripts
 \end{verbatim}
 
 Another Unix example: suppose your Python installation was built and
@@ -606,7 +606,7 @@ or, equivalently,
 \begin{verbatim}
 python setup.py install --home=~/python \
                         --install-purelib=lib \
-                        --install-platlib=lib.$PLAT \
+                        --install-platlib='lib.$PLAT' \
                         --install-scripts=scripts
                         --install-data=data
 \end{verbatim}