 |
 |
 |
Installing Python Modules |  |
 |
|
|
|
|
Installing Python Modules | |
|
|
The ``prefix scheme'' is useful when you wish to use one Python installation to perform the build/install (i.e., to run the setup script), but install modules into the third-party module directory of a different Python installation (or something that looks like a different 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 distributions put Python in /usr, rather than the more traditional /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 modules from source, you probably want them to go in /usr/local/lib/python1.X rather than /usr/lib/python1.X. This can be done with
/usr/bin/python setup.py install --prefix=/usr/local
Another possibility is a network filesystem where the name used to write to a remote directory is different from the name used to read it: for example, the Python interpreter accessed as /usr/local/bin/python might search for modules in /usr/local/lib/python1.X, but those modules would have to be installed to, say, /mnt/@server/export/lib/python1.X. This could be done with
/usr/local/bin/python setup.py install --prefix=/mnt/@server/export
In either case, the --prefix option defines the installation base, and the --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 --exec-prefix is not supplied, it defaults to --prefix. Files are installed as follows:
| Type of file | Installation Directory | Override option |
|---|---|---|
| pure module distribution | prefix/lib/python1.X/site-packages | --install-purelib |
| non-pure module distribution | exec-prefix/lib/python1.X/site-packages | --install-platlib |
| scripts | prefix/bin | --install-scripts |
| data | prefix/share | --install-data |
There is no requirement that --prefix or --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
--prefix and --exec-prefix supplied by
Python itself (as sys.prefix and sys.exec_prefix). Thus,
you might think you'll never use the prefix scheme, but every time you
run python setup.py install without any other options, you're
using it.
Note that installing extensions to an alternate Python installation has no effect on how those extensions are built: in particular, the Python header files (Python.h and friends) installed with the Python interpreter used to run the setup script will be used in compiling extensions. It is your responsibility to ensure that the interpreter 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 that the two interpreters are the same version of Python (possibly different builds, or possibly copies of the same build). (Of course, if your --prefix and --exec-prefix don't even point to an alternate Python installation, this is immaterial.)
|
|
|
Installing Python Modules | |
|
|