Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
C
cpython
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
Kirill Smelkov
cpython
Commits
4eaa3bfe
Commit
4eaa3bfe
authored
Apr 19, 2000
by
Greg Ward
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Reverted '\var' in the "standard installation location" table to '\filevar'.
Reformatted wide paragraphs.
parent
c402fa12
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
51 additions
and
49 deletions
+51
-49
Doc/inst/inst.tex
Doc/inst/inst.tex
+51
-49
No files found.
Doc/inst/inst.tex
View file @
4eaa3bfe
...
@@ -168,7 +168,7 @@ have to open a command prompt window and do it there; on Mac~OS ...
...
@@ -168,7 +168,7 @@ have to open a command prompt window and do it there; on Mac~OS ...
You should always run the setup command from the distribution root
You should always run the setup command from the distribution root
directory, i.e. the top-level subdirectory that the module source
directory, i.e. the top-level subdirectory that the module source
distribution unpacks into. For example, if you've just downloaded a
distribution unpacks into. For example, if you've just downloaded a
module source distribution
\file
{
foo-1.0.tar.gz
}
onto a Unix system, the
module source distribution
\file
{
foo-1.0.tar.gz
}
onto a Unix system, the
normal thing to do is:
normal thing to do is:
\begin{verbatim}
\begin{verbatim}
gunzip -c foo-1.0.tar.gz | tar xf - # unpacks into directory foo-1.0
gunzip -c foo-1.0.tar.gz | tar xf - # unpacks into directory foo-1.0
...
@@ -177,10 +177,11 @@ python setup.py install
...
@@ -177,10 +177,11 @@ python setup.py install
\end{verbatim}
\end{verbatim}
On Windows, you'd probably unpack the archive before opening the command
On Windows, you'd probably unpack the archive before opening the command
prompt. If you downloaded the archive file to
\file
{
C:
\textbackslash
{}
Temp
}
,
prompt. If you downloaded the archive file to
then it probably unpacked (depending on your software) into
\file
{
C:
\textbackslash
{}
Temp
}
, then it probably unpacked (depending on
\file
{
C:
\textbackslash
{}
Temp
\textbackslash
{}
foo-1.0
}
; from the command prompt window,
your software) into
you would then run
\file
{
C:
\textbackslash
{}
Temp
\textbackslash
{}
foo-1.0
}
; from the command
prompt window, you would then run
\begin{verbatim}
\begin{verbatim}
cd c:
\temp\foo
-1.0
cd c:
\temp\foo
-1.0
python setup.py install
python setup.py install
...
@@ -219,8 +220,8 @@ As implied above, the \command{build} command is responsible for putting
...
@@ -219,8 +220,8 @@ As implied above, the \command{build} command is responsible for putting
the files to install into a
\emph
{
build directory
}
. By default, this is
the files to install into a
\emph
{
build directory
}
. By default, this is
\file
{
build
}
under the distribution root; if you're excessively
\file
{
build
}
under the distribution root; if you're excessively
concerned with speed, or want to keep the source tree pristine, you can
concerned with speed, or want to keep the source tree pristine, you can
change the build directory with the
\longprogramopt
{
build-base
}
option.
For
change the build directory with the
\longprogramopt
{
build-base
}
option.
example:
For
example:
\begin{verbatim}
\begin{verbatim}
python setup.py build --build-base=/tmp/pybuild/foo-1.0
python setup.py build --build-base=/tmp/pybuild/foo-1.0
\end{verbatim}
\end{verbatim}
...
@@ -269,23 +270,23 @@ being installed is pure Python or contains extensions (``non-pure''):
...
@@ -269,23 +270,23 @@ being installed is pure Python or contains extensions (``non-pure''):
\begin{tableiv}
{
l|l|l|c
}{
textrm
}
%
\begin{tableiv}
{
l|l|l|c
}{
textrm
}
%
{
Platform
}{
Standard installation location
}{
Default value
}{
Notes
}
{
Platform
}{
Standard installation location
}{
Default value
}{
Notes
}
\lineiv
{
Unix (pure)
}
\lineiv
{
Unix (pure)
}
{
\filenq
{
\var
{
prefix
}
/lib/python1.6/site-packages
}}
{
\filenq
{
\
file
var
{
prefix
}
/lib/python1.6/site-packages
}}
{
\filenq
{
/usr/local/lib/python1.6/site-packages
}}
{
\filenq
{
/usr/local/lib/python1.6/site-packages
}}
{
(1)
}
{
(1)
}
\lineiv
{
Unix (non-pure)
}
\lineiv
{
Unix (non-pure)
}
{
\filenq
{
\var
{
exec-prefix
}
/lib/python1.6/site-packages
}}
{
\filenq
{
\
file
var
{
exec-prefix
}
/lib/python1.6/site-packages
}}
{
\filenq
{
/usr/local/lib/python1.6/site-packages
}}
{
\filenq
{
/usr/local/lib/python1.6/site-packages
}}
{
(1)
}
{
(1)
}
\lineiv
{
Windows
}
\lineiv
{
Windows
}
{
\filenq
{
\var
{
prefix
}}}
{
\filenq
{
\
file
var
{
prefix
}}}
{
\filenq
{
C:
\textbackslash
{}
Python
}}
{
\filenq
{
C:
\textbackslash
{}
Python
}}
{
(2)
}
{
(2)
}
\lineiv
{
Mac~OS (pure)
}
\lineiv
{
Mac~OS (pure)
}
{
\filenq
{
\var
{
prefix
}
:Lib
}}
{
\filenq
{
\
file
var
{
prefix
}
:Lib
}}
{
\filenq
{
Python:Lib
}
\XXX
{
???
}}
{
\filenq
{
Python:Lib
}
\XXX
{
???
}}
{}
{}
\lineiv
{
Mac~OS (non-pure)
}
\lineiv
{
Mac~OS (non-pure)
}
{
\var
{
prefix
}
:Mac:PlugIns
}
{
\
file
var
{
prefix
}
:Mac:PlugIns
}
{
\filenq
{
Python:Mac:PlugIns
}
\XXX
{
???
}}
{
\filenq
{
Python:Mac:PlugIns
}
\XXX
{
???
}}
{}
{}
\end{tableiv}
\end{tableiv}
...
@@ -298,8 +299,8 @@ being installed is pure Python or contains extensions (``non-pure''):
...
@@ -298,8 +299,8 @@ being installed is pure Python or contains extensions (``non-pure''):
any Unix-like system), the default
\filevar
{
prefix
}
and
any Unix-like system), the default
\filevar
{
prefix
}
and
\filevar
{
exec-prefix
}
are
\file
{
/usr/local
}
.
\filevar
{
exec-prefix
}
are
\file
{
/usr/local
}
.
\item
[(2)]
The default installation directory on Windows was
\item
[(2)]
The default installation directory on Windows was
\file
{
C:
\textbackslash
{}
Program Files
\textbackslash
{}
Python
}
under
Python 1.6a1,
\file
{
C:
\textbackslash
{}
Program Files
\textbackslash
{}
Python
}
under
1.5.2, and earlier.
Python 1.6a1,
1.5.2, and earlier.
\end{description}
\end{description}
\filevar
{
prefix
}
and
\filevar
{
exec-prefix
}
stand for the directories
\filevar
{
prefix
}
and
\filevar
{
exec-prefix
}
stand for the directories
...
@@ -397,9 +398,9 @@ option. Lazy typists can just type a tilde (\code{\textasciitilde}); the
...
@@ -397,9 +398,9 @@ option. Lazy typists can just type a tilde (\code{\textasciitilde}); the
python setup.py install --home=~
python setup.py install --home=~
\end{verbatim}
\end{verbatim}
The
\longprogramopt
{
home
}
option defines the installation base
directory. Files
The
\longprogramopt
{
home
}
option defines the installation base
are installed to the following directories under the installation bas
e
directory. Files are installed to the following directories under th
e
as follows:
installation base
as follows:
\installscheme
{
home
}{
/lib/python
}
\installscheme
{
home
}{
/lib/python
}
{
home
}{
/lib/python
}
{
home
}{
/lib/python
}
{
home
}{
/bin
}
{
home
}{
/bin
}
...
@@ -438,30 +439,31 @@ could be done with
...
@@ -438,30 +439,31 @@ could be done with
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
\end{verbatim}
\end{verbatim}
In either case, the
\longprogramopt
{
prefix
}
option defines the
installation
In either case, the
\longprogramopt
{
prefix
}
option defines the
base, and the
\longprogramopt
{
exec-prefix
}
option defines the platform-specific
installation base, and the
\longprogramopt
{
exec-prefix
}
option defines
installation base, which is used for platform-specific files.
the platform-specific installation base, which is used for
(Currently, this just means non-pure module distributions, but could b
e
platform-specific files. (Currently, this just means non-pure modul
e
expanded to C libraries, binary executables, etc.) If
distributions, but could be expanded to C libraries, binary executables,
\longprogramopt
{
exec-prefix
}
is not supplied, it defaults to
\longprogramopt
{
prefix
}
.
etc.) If
\longprogramopt
{
exec-prefix
}
is not supplied, it defaults to
Files are installed as follows:
\longprogramopt
{
prefix
}
.
Files are installed as follows:
\installscheme
{
prefix
}{
/lib/python1.
\filevar
{
X
}
/site-packages
}
\installscheme
{
prefix
}{
/lib/python1.
\filevar
{
X
}
/site-packages
}
{
exec-prefix
}{
/lib/python1.
\filevar
{
X
}
/site-packages
}
{
exec-prefix
}{
/lib/python1.
\filevar
{
X
}
/site-packages
}
{
prefix
}{
/bin
}
{
prefix
}{
/bin
}
{
prefix
}{
/share
}
{
prefix
}{
/share
}
There is no requirement that
\longprogramopt
{
prefix
}
or
\longprogramopt
{
exec-prefix
}
There is no requirement that
\longprogramopt
{
prefix
}
or
actually point to an alternate Python installation; if the directories
\longprogramopt
{
exec-prefix
}
actually point to an alternate Python
listed above do not already exist, they are created at installation
installation; if the directories listed above do not already exist, they
time.
are created at installation
time.
Incidentally, the real reason the prefix scheme is important is simply
Incidentally, the real reason the prefix scheme is important is simply
that a standard Unix installation uses the prefix scheme, but with
that a standard Unix installation uses the prefix scheme, but with
\longprogramopt
{
prefix
}
and
\longprogramopt
{
exec-prefix
}
supplied by Python itself (as
\longprogramopt
{
prefix
}
and
\longprogramopt
{
exec-prefix
}
supplied by
\code
{
sys.prefix
}
and
\code
{
sys.exec
\_
prefix
}
). Thus, you might think
Python itself (as
\code
{
sys.prefix
}
and
\code
{
sys.exec
\_
prefix
}
). Thus,
you'll never use the prefix scheme, but every time you run
\code
{
python
you might think you'll never use the prefix scheme, but every time you
setup.py install
}
without any other options, you're using it.
run
\code
{
python setup.py install
}
without any other options, you're
using it.
Note that installing extensions to an alternate Python installation has
Note that installing extensions to an alternate Python installation has
no effect on how those extensions are built: in particular, the Python
no effect on how those extensions are built: in particular, the Python
...
@@ -472,8 +474,8 @@ used to run extensions installed in this way is compatibile with the
...
@@ -472,8 +474,8 @@ used to run extensions installed in this way is compatibile with the
interpreter used to build them. The best way to do this is to ensure
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
that the two interpreters are the same version of Python (possibly
different builds, or possibly copies of the same build). (Of course, if
different builds, or possibly copies of the same build). (Of course, if
your
\longprogramopt
{
prefix
}
and
\longprogramopt
{
exec-prefix
}
don't even
point to an
your
\longprogramopt
{
prefix
}
and
\longprogramopt
{
exec-prefix
}
don't even
alternate Python installation, this is immaterial.)
point to an
alternate Python installation, this is immaterial.)
\subsection
{
Alternate installation: Windows
}
\subsection
{
Alternate installation: Windows
}
...
@@ -481,18 +483,18 @@ alternate Python installation, this is immaterial.)
...
@@ -481,18 +483,18 @@ alternate Python installation, this is immaterial.)
Since Windows has no conception of a user's home directory, and since
Since Windows has no conception of a user's home directory, and since
the standard Python installation under Windows is simpler than that
the standard Python installation under Windows is simpler than that
under Unix, there's no point in having separate
\longprogramopt
{
prefix
}
and
under Unix, there's no point in having separate
\longprogramopt
{
prefix
}
\longprogramopt
{
home
}
options. Just use the
\longprogramopt
{
prefix
}
option to specify
and
\longprogramopt
{
home
}
options. Just use the
\longprogramopt
{
prefix
}
a base directory, e.g.
option to specify
a base directory, e.g.
\begin{verbatim}
\begin{verbatim}
python setup.py install --prefix="
\Temp\Python
"
python setup.py install --prefix="
\Temp\Python
"
\end{verbatim}
\end{verbatim}
to install modules to the
\file
{
\textbackslash
{}
Temp
}
directory on the current
to install modules to the
\file
{
\textbackslash
{}
Temp
}
directory on the current
drive.
drive.
The installation base is defined by the
\longprogramopt
{
prefix
}
option;
the
The installation base is defined by the
\longprogramopt
{
prefix
}
option;
\longprogramopt
{
exec-prefix
}
option is not supported under Windows. Files are
the
\longprogramopt
{
exec-prefix
}
option is not supported under Windows.
installed as follows:
Files are
installed as follows:
\installscheme
{
prefix
}{}
\installscheme
{
prefix
}{}
{
prefix
}{}
{
prefix
}{}
{
prefix
}{
\textbackslash
{}
Scripts
}
{
prefix
}{
\textbackslash
{}
Scripts
}
...
@@ -504,8 +506,8 @@ installed as follows:
...
@@ -504,8 +506,8 @@ installed as follows:
Like Windows, Mac~OS has no notion of home directories (or even of
Like Windows, Mac~OS has no notion of home directories (or even of
users), and a fairly simple standard Python installation. Thus, only a
users), and a fairly simple standard Python installation. Thus, only a
\longprogramopt
{
prefix
}
option is needed. It defines the installation
base, and
\longprogramopt
{
prefix
}
option is needed. It defines the installation
files are installed under it as follows:
base, and
files are installed under it as follows:
\XXX
{
how do MacPython users run the interpreter with command-line args?
}
\XXX
{
how do MacPython users run the interpreter with command-line args?
}
...
@@ -541,16 +543,16 @@ how you define a custom installation scheme. These override options can
...
@@ -541,16 +543,16 @@ how you define a custom installation scheme. These override options can
be relative, absolute, or explicitly defined in terms of one of the
be relative, absolute, or explicitly defined in terms of one of the
installation base directories. (There are two installation base
installation base directories. (There are two installation base
directories, and they are normally the same---they only differ when you
directories, and they are normally the same---they only differ when you
use the Unix ``prefix scheme'' and supply different
\longprogramopt
{
prefix
}
and
use the Unix ``prefix scheme'' and supply different
\longprogramopt
{
exec-prefix
}
options.)
\longprogramopt
{
prefix
}
and
\longprogramopt
{
exec-prefix
}
options.)
For example, say you're installing a module distribution to your home
For example, say you're installing a module distribution to your home
directory under Unix---but you want scripts to go in
directory under Unix---but you want scripts to go in
\file
{
\textasciitilde
/scripts
}
rather than
\file
{
\textasciitilde
/bin
}
.
As you might
\file
{
\textasciitilde
/scripts
}
rather than
\file
{
\textasciitilde
/bin
}
.
expect, you can override this directory with the
As you might
expect, you can override this directory with the
\longprogramopt
{
install-scripts
}
option; in this case, it makes most
sense to
\longprogramopt
{
install-scripts
}
option; in this case, it makes most
s
upply a relative path, which will be interpreted relative to the
s
ense to supply a relative path, which will be interpreted relative to
installation base directory (your home directory, in this case):
the
installation base directory (your home directory, in this case):
\begin{verbatim}
\begin{verbatim}
python setup.py install --home --install-scripts=scripts
python setup.py install --home --install-scripts=scripts
\end{verbatim}
\end{verbatim}
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment