\lineii{Unix}{gzipped tar file (\file{.tar.gz})}
\lineii{Windows}{zip file}
\end{tableii}
-You can specify as many formats as you like using the \option{--formats}
+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
\begin{verbatim}
python setup.py sdist --manifest-only
\end{verbatim}
-(\option{--manifest-only} implies \option{--force-manifest}.)
+(\longprogramopt{manifest-only} implies \longprogramopt{force-manifest}.)
If you don't want to use the default file set, you can supply the
-\option{--no-defaults} option. If you use \option{--no-defaults} and
+\longprogramopt{no-defaults} option. If you use \longprogramopt{no-defaults} and
don't supply a manifest template (or it's empty, or nothing matches the
patterns in it), then your source distribution will be empty.
\XXX{filenames are inaccurate here!}
-The \command{bdist} command has a \option{--format} option, similar to
+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,
\begin{verbatim}
\end{description}
You don't have to use the \command{bdist} command with the
-\option{--formats} option; you can also use the command that directly
+\longprogramopt{formats} option; you can also use the command that directly
implements the format you're interested in. Many of these
\command{bdist} ``sub-commands'' actually generate several similar
formats; for instance, the \command{bdist\_dumb} command generates all
the files to install into a \emph{build directory}. By default, this is
\file{build} under the distribution root; if you're excessively
concerned with speed, or want to keep the source tree pristine, you can
-change the build directory with the \option{--build-base} option. For
+change the build directory with the \longprogramopt{build-base} option. For
example:
\begin{verbatim}
python setup.py build --build-base=/tmp/pybuild/foo-1.0
{Override option}
\lineiii{pure module distribution}
{\filevar{#1}\filenq{#2}}
- {\option{--install-purelib}}
+ {\longprogramopt{install-purelib}}
\lineiii{non-pure module distribution}
{\filevar{#3}\filenq{#4}}
- {\option{--install-platlib}}
+ {\longprogramopt{install-platlib}}
\lineiii{scripts}
{\filevar{#5}\filenq{#6}}
- {\option{--install-scripts}}
+ {\longprogramopt{install-scripts}}
\lineiii{data}
{\filevar{#7}\filenq{#8}}
- {\option{--install-data}}
+ {\longprogramopt{install-data}}
\end{tableiii}}
\section{Alternate Installation}
\begin{verbatim}
python setup.py install --home=<dir>
\end{verbatim}
-where you can supply any directory you like for the \option{home}
+where you can supply any directory you like for the \longprogramopt{home}
option. Lazy typists can just type a tilde (\code{\tilde}); the
\command{install} command will expand this to your home directory:
\begin{verbatim}
python setup.py install --home=~
\end{verbatim}
-The \option{home} option defines the installation base directory. Files
+The \longprogramopt{home} option defines the installation base directory. Files
are installed to the following directories under the installation base
as follows:
\installscheme{home}{/lib/python}
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
\end{verbatim}
-In either case, the \option{prefix} option defines the installation
-base, and the \option{exec-prefix} option defines the platform-specific
+In either case, the \longprogramopt{prefix} option defines the installation
+base, and the \longprogramopt{exec-prefix} option defines the platform-specific
installation base, which is used for platform-specific files.
(Currently, this just means non-pure module distributions, but could be
expanded to C libraries, binary executables, etc.) If
-\option{exec-prefix} is not supplied, it defaults to \option{prefix}.
+\longprogramopt{exec-prefix} is not supplied, it defaults to \longprogramopt{prefix}.
Files are installed as follows:
\installscheme{prefix}{/lib/python1.\filevar{X}/site-packages}
{prefix}{/bin}
{prefix}{/share}
-There is no requirement that \option{prefix} or \option{exec-prefix}
+There is no requirement that \longprogramopt{prefix} or \longprogramopt{exec-prefix}
actually point to an alternate Python installation; if the directories
listed above do not already exist, they are created at installation
time.
Incidentally, the real reason the prefix scheme is important is simply
that a standard Unix installation uses the prefix scheme, but with
-\option{prefix} and \option{exec-prefix} supplied by Python itself (as
+\longprogramopt{prefix} and \longprogramopt{exec-prefix} supplied by Python itself (as
\code{sys.prefix} and \code{sys.exec\_prefix}). Thus, you might think
you'll never use the prefix scheme, but every time you run \code{python
setup.py install} without any other options, you're using it.
interpreter used to build them. The best way to do this is to ensure
that the two interpreters are the same version of Python (possibly
different builds, or possibly copies of the same build). (Of course, if
-your \option{prefix} and \option{exec-prefix} don't even point to an
+your \longprogramopt{prefix} and \longprogramopt{exec-prefix} don't even point to an
alternate Python installation, this is immaterial.)
Since Windows has no conception of a user's home directory, and since
the standard Python installation under Windows is simpler than that
-under Unix, there's no point in having separate \option{prefix} and
-\option{home} options. Just use the \option{prefix} option to specify
+under Unix, there's no point in having separate \longprogramopt{prefix} and
+\longprogramopt{home} options. Just use the \longprogramopt{prefix} option to specify
a base directory, e.g.
\begin{verbatim}
python setup.py install --prefix="\Temp\Python"
to install modules to the \file{\bslash{}Temp} directory on the current
drive.
-The installation base is defined by the \option{prefix} option; the
-\option{exec-prefix} option is not supported under Windows. Files are
+The installation base is defined by the \longprogramopt{prefix} option; the
+\longprogramopt{exec-prefix} option is not supported under Windows. Files are
installed as follows:
\installscheme{prefix}{}
{prefix}{}
Like Windows, Mac~OS has no notion of home directories (or even of
users), and a fairly simple standard Python installation. Thus, only a
-\option{prefix} option is needed. It defines the installation base, and
+\longprogramopt{prefix} option is needed. It defines the installation base, and
files are installed under it as follows:
\XXX{how do MacPython users run the interpreter with command-line args?}
be relative, absolute, or explicitly defined in terms of one of the
installation base directories. (There are two installation base
directories, and they are normally the same---they only differ when you
-use the Unix ``prefix scheme'' and supply different \option{prefix} and
-\option{exec-prefix} options.)
+use the Unix ``prefix scheme'' and supply different \longprogramopt{prefix} and
+\longprogramopt{exec-prefix} options.)
For example, say you're installing a module distribution to your home
directory under Unix---but you want scripts to go in
\file{\tilde/scripts} rather than \file{\tilde/bin}. As you might
expect, you can override this directory with the
-\option{install-scripts} option; in this case, it makes most sense to
+\longprogramopt{install-scripts} option; in this case, it makes most sense to
supply a relative path, which will be interpreted relative to the
installation base directory (your home directory, in this case):
\begin{verbatim}
installed with a prefix of \file{/usr/local/python}, so under a standard
installation scripts will wind up in \file{/usr/local/python/bin}. If
you want them in \file{/usr/local/bin} instead, you would supply this
-absolute directory for the \option{install-scripts} option:
+absolute directory for the \longprogramopt{install-scripts} option:
\begin{verbatim}
python setup.py install --install-scripts=/usr/local/bin
\end{verbatim}
projects / python / commitdiff