安装python模块(旧版)

作者

格雷格·沃德

注解

整个 distutils 软件包已弃用,将在Python 3.12中删除。本文档仅作为参考保留,并将随软件包一起删除。请参阅 What's New 有关更多信息,请登录。

参见

安装python模块

最新的模块安装文档。对于常规的python用法,您几乎肯定想要那个文档而不是这个文档。

注解

本文件仅保留至 setuptools https://setuptools.readthedocs.io/en/latest/setuptools.html上的文档独立地涵盖了此处当前包含的所有相关信息。

注解

本指南仅涵盖构建和分发扩展的基本工具,这些扩展是作为此版本的Python的一部分提供的。第三方工具提供了更易于使用和更安全的替代方案。参考 quick recommendations section _有关详细信息,请参阅《Python打包用户指南》。

介绍

在python 2.0中, distutils API首先被添加到标准库中。这为Linux发行版维护人员提供了将python项目转换为Linux发行版包的标准方法,并为系统管理员提供了将它们直接安装到目标系统上的标准方法。

自python 2.0发布以来的许多年里,将构建系统和包安装程序紧密耦合到语言运行时发布周期已被证明是有问题的,现在建议项目使用 pip 软件包安装程序和 setuptools 构建系统,而不是使用 distutils 直接。

安装python模块分发python模块 了解更多详细信息。

只有在我们确信 setuptools 文档涵盖了所有需要的内容。

基于distuils的源分布

如果您下载了一个模块源代码分发版,您可以很快地知道它是否是以标准方式打包和分发的,即使用distutils。首先,分发的名称和版本号将突出显示在下载的存档文件的名称中,例如 foo-1.0.tar.gzwidget-0.9.7.zip . 接下来,归档文件将解包到一个同名目录中: foo-1.0widget-0.9.7 .此外,分发将包含一个安装脚本 setup.py 和一个名为 README.txt 或者可能只是 README ,这应该解释构建和安装模块分发是从终端运行一个命令的简单问题:

python setup.py install

对于Windows,应该从命令提示窗口运行此命令 (Start ‣ Accessories ):

setup.py install

如果所有这些都是正确的,那么您已经知道如何构建和安装刚刚下载的模块:运行上面的命令。除非您需要以非标准方式安装东西或定制构建过程,否则您并不真正需要本手册。或者更确切地说,上面的命令就是您需要从本手册中得到的一切。

标准建造和安装

如第节所述 基于distuils的源分布 ,使用distutils构建和安装模块分发通常是从终端运行的一个简单命令:

python setup.py install

平台变化

您应该始终从分发根目录(即模块源分发解包到的顶级子目录)运行安装命令。例如,如果您刚下载了一个模块源分发版 foo-1.0.tar.gz 在UNIX系统上,通常要做的事情是:

gunzip -c foo-1.0.tar.gz | tar xf -    # unpacks into directory foo-1.0
cd foo-1.0
python setup.py install

在Windows上,您可能会下载 foo-1.0.zip . 如果您将存档文件下载到 C:\Temp 然后它会打开 C:\Temp\foo-1.0 ;可以将存档操纵器与图形用户界面(如winzip)或命令行工具(如 unzippkunzip )打开归档文件。然后,打开命令提示窗口并运行:

cd c:\Temp\foo-1.0
python setup.py install

拆分任务

运行 setup.py install 在一次运行中生成和安装所有模块。如果您更类似于增量工作——如果您想要定制构建过程,或者事情出了问题,那么特别有用——您可以使用安装脚本一次完成一件事情。当构建和安装将由不同的用户完成时,这尤其有用——例如,您可能希望构建一个模块分发版,并将其交给系统管理员进行安装(或者使用超级用户权限自己进行安装)。

例如,通过两次调用安装脚本,您可以在一个步骤中构建所有内容,然后在第二个步骤中安装所有内容:

python setup.py build
python setup.py install

如果您这样做,您会注意到运行 install 命令首先运行 build 命令,在这种情况下,它很快注意到它没有任何作用,因为 build 目录是最新的。

如果您所做的只是安装从网络上下载的模块,那么您可能不需要这种能力来经常分解问题,但是对于更高级的任务来说,它非常方便。如果您开始分发自己的python模块和扩展,您将单独运行许多distuils命令。

如何开展工作

正如上面所暗示的那样, build 命令负责将要安装的文件放入 建立目录 . 默认情况下,这是 build 在分布根目录下;如果您过分关注速度,或者希望保持源码树的原始性,可以使用 --build-base 选项。例如::

python setup.py build --build-base=/path/to/pybuild/foo-1.0

(或者您可以使用系统或个人distutils配置文件中的指令永久执行此操作;请参见第节 distutils配置文件 一般来说,这是不必要的。

生成树的默认布局如下:

--- build/ --- lib/
or
--- build/ --- lib.<plat>/
               temp.<plat>/

在哪里? <plat> 扩展到当前操作系统/硬件平台和Python版本的简要描述。第一张表格,只有一张 lib 目录,用于“纯模块分发”--即仅包含纯Python模块的模块分发。如果模块分布包含任何扩展(用C/C++编写的模块),那么第二种形式有两个 <plat> 使用目录。在这种情况下, temp.{plat} 目录保存编译/链接进程生成的临时文件,这些文件实际上没有安装。在这两种情况下, lib (或) lib.{plat} )目录包含将要安装的所有python模块(纯python和扩展)。

将来,将添加更多目录来处理python脚本、文档、二进制可执行文件,以及处理安装python模块和应用程序所需的其他内容。

安装工作原理

build 命令运行(无论您是显式运行它,还是 install 命令为你做的),的工作 install 命令相对简单:它所要做的就是复制 build/lib (或) build/lib.{plat} )到您选择的安装目录。

如果您不选择安装目录,也就是说,如果您只是运行 setup.py install ---然后 install 命令安装到第三方python模块的标准位置。这个位置因平台和构建/安装python本身的方式而异。在Unix(以及基于Unix的Mac OS X)上,它还取决于所安装的模块分发是纯Python还是包含扩展(“非纯”):

Platform

标准安装位置

默认值

笔记

UNIX(纯)

prefix/lib/pythonX.Y/site-packages

/usr/local/lib/pythonX.Y/site-packages

(1)

UNIX(非纯)

exec-prefix/lib/pythonX.Y/site-packages

/usr/local/lib/pythonX.Y/site-packages

(1)

Windows

prefix\Lib\site-packages

C:\PythonXY\Lib\site-packages

(2)

笔记:

  1. 大多数Linux发行版都将python作为系统的标准部分,因此 {prefix}{exec-prefix} 通常都是 /usr 在Linux上。如果您自己在Linux(或任何类似于Unix的系统)上构建python,则默认 {prefix}{exec-prefix}/usr/local .

  2. Windows上的默认安装目录是 C:\Program Files\Python 在python 1.6a1、1.5.2和更早版本下。

{prefix}{exec-prefix} 代表安装了python的目录,以及在运行时找到其库的位置。它们在Windows下总是相同的,在Unix和Mac OS X下也常常相同。您可以了解python安装的用途。 {prefix}{exec-prefix} 通过在交互模式下运行python并键入一些简单的命令。在Unix下,只需键入 python 在shell提示下。在Windows下,选择 Start ‣ Programs ‣ Python X.Y ‣ Python (command line) . 一旦解释器启动,您就可以在提示下键入python代码。例如,在我的Linux系统上,我键入下面所示的三个python语句,并获得如图所示的输出,以找出 {prefix}{exec-prefix}

Python 2.4 (#26, Aug  7 2004, 17:19:02)
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.prefix
'/usr'
>>> sys.exec_prefix
'/usr'

此文档中使用了其他几个占位符: {X.Y} 例如,代表python的版本 3.2{abiflags} 将替换为 sys.abiflags 或者没有定义ABI标志的平台的空字符串; {distname} 将替换为正在安装的模块分发的名称。点和大写在路径中很重要;例如,使用 python3.2 在Unix上通常使用 Python32 在Windows上。

如果您不想将模块安装到标准位置,或者您没有在此位置写入的权限,那么您需要阅读第节中有关备用安装的内容。 备用安装 . 如果您想更严格地自定义安装目录,请参见 自定义安装 在自定义安装时。

备用安装

通常,将模块安装到第三方Python模块的标准位置以外的位置是必要的或可取的。例如,在UNIX系统上,您可能没有写入标准第三方模块目录的权限。或者,您可能希望在将某个模块作为本地Python安装的标准部分之前对其进行尝试。当升级已经存在的分发版时尤其如此:在实际升级之前,您需要确保现有的脚本库仍然与新版本一起工作。

ditudil install 命令旨在使将模块分发安装到另一个位置变得简单和轻松。基本思想是为安装提供一个基本目录,并且 install 命令选择一组目录(称为 安装方案 )在这个基本目录下安装文件。不同平台的详细信息不同,请阅读以下适用于您的部分。

请注意,各种备选安装方案相互排斥:您可以通过 --user--home--prefix--exec-prefix--install-base--install-platbase 但是你不能从这些组中混合。

备用安装:用户方案

此方案旨在为对全局站点包目录没有写权限或不希望安装到其中的用户提供最方便的解决方案。它是通过一个简单的选项启用的:

python setup.py install --user

文件将安装到的子目录中 site.USER_BASE (写成) {userbase} 此后)。此方案在同一位置安装纯Python模块和扩展模块(也称为 site.USER_SITE )以下是Unix的值,包括Mac OS X:

文件类型

安装目录

模块

userbase/lib/pythonX.Y/site-packages

脚本

userbase/bin

数据

userbase

C标题

userbase/include/pythonX.Yabiflags/distname

以下是Windows上使用的值:

文件类型

安装目录

模块

userbase\PythonXY\site-packages

脚本

userbase\PythonXY\Scripts

数据

userbase

C标题

userbase\PythonXY\Include{distname}

与下面描述的其他方案相比,使用此方案的优势在于,用户站点包目录在正常情况下始终包含在 sys.path (见 site 有关详细信息),这意味着在运行 setup.py 用于完成安装的脚本。

这个 build_ext 命令还具有 --user 添加选项 {userbase}/include 到头文件的编译器搜索路径 {userbase}/lib 到库的编译器搜索路径以及共享C库的运行时搜索路径(rpath)。

替代安装:家庭方案

“主方案”背后的想法是您构建并维护一个个人的Python模块存储库。这个方案的名称源于Unix上的“home”目录的概念,因为对于Unix用户来说,使其home目录的布局类似于 /usr//usr/local/ . 任何人都可以使用此方案,无论他们安装的操作系统是什么。

安装新的模块分发版非常简单:

python setup.py install --home=<dir>

您可以在其中为 --home 选择权。在UNIX上,懒惰的打字员只需键入一个颚化符 (~install 命令将此目录扩展到主目录:

python setup.py install --home=~

要让python找到与此方案一起安装的发行版,您可能必须 modify Python's search path 或编辑 sitecustomize (见 site 调用 site.addsitedir() 或编辑 sys.path .

这个 --home 选项定义安装基目录。文件安装到安装库下的以下目录中,如下所示:

文件类型

安装目录

模块

home/lib/python

脚本

home/bin

数据

home

C标题

home/include/python/distname

(如果你在 Windows 上,用反斜杠代替斜杠。)

备用安装:unix(前缀方案)

如果您希望使用一个python安装来执行构建/安装(即运行安装脚本),但将模块安装到另一个python安装的第三方模块目录中(或类似于另一个python安装的目录),则“前缀方案”非常有用。如果这听起来有点不寻常,那就是——这就是为什么用户和家庭计划出现在前面的原因。但是,至少有两种已知的情况下前缀方案是有用的。

首先,考虑许多Linux发行版将python /usr 而不是更传统的 /usr/local . 这是完全合适的,因为在这些情况下,Python是“系统”的一部分,而不是本地附加组件。但是,如果您要从源代码安装python模块,您可能希望它们进入 /usr/local/lib/python2.{X} 而不是 /usr/lib/python2.{X} . 这可以通过以下方式完成:

/usr/bin/python setup.py install --prefix=/usr/local

另一种可能是网络文件系统,其中用于写入远程目录的名称与用于读取该目录的名称不同:例如,python解释器访问时 /usr/local/bin/python 可能在中搜索模块 /usr/local/lib/python2.{X} 但是这些模块必须安装到,比如, /mnt/{@server}/export/lib/python2.{X} . 这可以通过以下方式完成:

/usr/local/bin/python setup.py install --prefix=/mnt/@server/export

在这两种情况下, --prefix 选项定义安装基础,以及 --exec-prefix 选项定义平台特定的安装库,用于平台特定的文件。(目前,这仅仅意味着非纯模块分发,但可以扩展到C库、二进制可执行文件等)如果 --exec-prefix 未提供,默认为 --prefix . 文件安装如下:

文件类型

安装目录

python模块

prefix/lib/pythonX.Y/site-packages

扩展模块

exec-prefix/lib/pythonX.Y/site-packages

脚本

prefix/bin

数据

prefix

C标题

prefix/include/pythonX.Yabiflags/distname

没有要求 --prefix--exec-prefix 实际上指向另一个python安装;如果上面列出的目录不存在,则在安装时创建它们。

顺便说一句,前缀方案之所以重要,是因为标准的UNIX安装使用前缀方案,但是 --prefix--exec-prefix 由python本身提供 sys.prefixsys.exec_prefix . 因此,您可能认为永远不会使用前缀方案,但每次运行时 python setup.py install 如果没有其他选择,你就可以使用它。

注意,将扩展安装到另一个python安装中不会影响这些扩展的构建方式:特别是python头文件 (Python.h 与用于运行安装脚本的python解释器一起安装的,将用于编译扩展。您有责任确保用于运行以这种方式安装的扩展的解释器与用于构建扩展的解释器兼容。做到这一点的最佳方法是确保两个解释程序是同一版本的Python(可能是不同的版本,也可能是同一版本的副本)。(当然,如果您的 --prefix--exec-prefix 甚至不要指向另一个python安装,这是无关紧要的。)

备用安装:Windows(前缀方案)

Windows没有用户主目录的概念,而且由于Windows下的标准python安装比Unix下的简单,因此 --prefix 选项通常用于在Windows的不同位置安装其他软件包。::

python setup.py install --prefix="\Temp\Python"

将模块安装到 \Temp\Python 当前驱动器上的目录。

安装基础由 --prefix 选择权; --exec-prefix Windows不支持选项,这意味着纯Python模块和扩展模块安装在同一位置。文件安装如下:

文件类型

安装目录

模块

prefix\Lib\site-packages

脚本

prefix\Scripts

数据

prefix

C标题

prefix\Include{distname}

自定义安装

有时,第节中描述的替代安装方案 备用安装 只是不要做你想做的。您可能只需要调整一个或两个目录,同时将所有内容保持在同一个基目录下,或者您可能需要完全重新定义安装方案。无论哪种情况,您都在创建 自定义安装方案 .

要创建自定义安装方案,请从一个备用方案开始,并使用以下选项覆盖用于各种类型文件的某些安装目录:

文件类型

超越选项

python模块

--install-purelib

扩展模块

--install-platlib

所有模块

--install-lib

脚本

--install-scripts

数据

--install-data

C标题

--install-headers

这些覆盖选项可以是相对的、绝对的,也可以是根据一个安装基目录显式定义的。(有两个安装基目录,它们通常是相同的---它们只有在使用unix“前缀方案”并提供不同的 --prefix--exec-prefix 选择;使用 --install-lib 将重写为计算或给定的值 --install-purelib--install-platlib ,对于不区分python和扩展模块的方案,建议使用。)

例如,假设您正在Unix下安装一个模块分发到您的主目录——但是您希望脚本进入 ~/scripts 而不是 ~/bin . 如您所料,您可以使用 --install-scripts 选项;在这种情况下,最有意义的做法是提供一个相对路径,该路径将相对于安装基目录(在本例中是您的主目录)进行解释:

python setup.py install --home=~ --install-scripts=scripts

另一个UNIX示例:假设您的python安装是以前缀 /usr/local/python ,因此在标准安装脚本中 /usr/local/python/bin . 如果你想让他们进来 /usr/local/bin 相反,您将为 --install-scripts 选项:

python setup.py install --install-scripts=/usr/local/bin

(这将使用“prefix scheme”执行安装,其中prefix是安装了Python解释器的--- /usr/local/python 在这种情况下)

如果在Windows上维护python,您可能希望第三方模块位于 {prefix} 而不是直接进入 {prefix} 本身。这几乎和定制脚本安装目录一样简单——您只需记住,有两种类型的模块需要担心:python和extension模块,这两种模块都可以方便地由一个选项控制:

python setup.py install --install-lib=Site

指定的安装目录相对于 {prefix} .当然,还必须确保该目录位于Python的模块搜索路径中,例如 .pth 站点目录中的文件(请参见 site )见节 修改python的搜索路径 了解如何修改python的搜索路径。

如果要定义整个安装方案,只需提供所有安装目录选项。建议的方法是提供相对路径;例如,如果要在下面维护所有与python模块相关的文件 python 在主目录中,如果要为使用主目录的每个平台分别定义一个目录,可以定义以下安装方案:

python setup.py install --home=~ \
                        --install-purelib=python/lib \
                        --install-platlib=python/lib.$PLAT \
                        --install-scripts=python/scripts
                        --install-data=python/data

或者,等价地:

python setup.py install --home=~/python \
                        --install-purelib=lib \
                        --install-platlib='lib.$PLAT' \
                        --install-scripts=scripts
                        --install-data=data

$PLAT 不是(必须)一个环境变量---它将在解析命令行选项时由distuils扩展,就像解析配置文件时那样。

显然,每次安装新的模块分发版时都要指定整个安装方案是非常繁琐的。因此,可以将这些选项放入distutils配置文件(请参见第节 distutils配置文件 ):

[install]
install-base=$HOME
install-purelib=python/lib
install-platlib=python/lib.$PLAT
install-scripts=python/scripts
install-data=python/data

或者,等价地,

[install]
install-base=$HOME/python
install-purelib=lib
install-platlib=lib.$PLAT
install-scripts=scripts
install-data=data

注意这两个是 not 如果在运行安装脚本时提供不同的安装基目录,则等效。例如:

python setup.py install --install-base=/tmp

将纯模块安装到 /tmp/python/lib 在第一种情况下, /tmp/lib 在第二种情况下。(对于第二种情况,您可能希望提供 /tmp/python

你可能注意到了 $HOME$PLAT 在示例配置文件输入中。这些是distuils配置变量,与环境变量非常相似。实际上,您可以在具有这样一个概念的平台上的配置文件中使用环境变量,但是distuils还定义了一些可能不在您的环境中的额外变量,例如 $PLAT . (当然,在没有环境变量的系统上,例如Mac OS 9,distutils提供的配置变量是唯一可以使用的配置变量。)请参见第节 distutils配置文件 有关详细信息。

注解

当A virtual environment 如果激活,则所有distuils配置文件中更改安装路径的任何选项都将被忽略,以防止无意中在虚拟环境之外安装项目。

修改python的搜索路径

当python解释器执行 import 语句,它沿着搜索路径搜索python代码和扩展模块。在构建解释器时,路径的默认值被配置为python二进制文件。您可以通过导入 sys 模块和打印值 sys.path . ::

$ python
Python 2.2 (#11, Oct  3 2002, 13:31:27)
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/local/lib/python2.3', '/usr/local/lib/python2.3/plat-linux2',
 '/usr/local/lib/python2.3/lib-tk', '/usr/local/lib/python2.3/lib-dynload',
 '/usr/local/lib/python2.3/site-packages']
>>>

中的空字符串 sys.path 表示当前工作目录。

本地安装包的预期约定是将它们放入 {...}/site-packages/ 目录,但您可能希望将python模块安装到某个任意目录中。例如,您的站点可能有一个惯例,将与Web服务器相关的所有软件保存在 /www . 然后,附加的python模块可能属于 /www/python ,并且为了导入它们,必须将此目录添加到 sys.path . 添加目录有几种不同的方法。

最方便的方法是将路径配置文件添加到已经在python路径上的目录中,通常添加到 .../site-packages/ 目录。路径配置文件的扩展名为 .pth ,并且每行必须包含一个将附加到 sys.path . (因为新路径附加到 sys.path ,添加的目录中的模块不会覆盖标准模块。这意味着您不能使用此机制安装标准模块的固定版本。)

路径可以是绝对路径或相对路径,在这种情况下,它们是相对于包含 .pth 文件。参见 site 模块了解更多信息。

稍微不方便的方法是编辑 site.py 在python的标准库中,并修改 sys.path . site.py 在执行python解释器时自动导入,除非 -S 开关用于抑制这种行为。所以你可以简单地编辑 site.py 并添加两行:

import sys
sys.path.append('/www/python/')

但是,如果您重新安装了同一个主要版本的python(例如,当从2.2升级到2.2.2时)。 site.py 将被库存版本覆盖。在安装之前,您必须记住它已被修改并保存了一个副本。

有两个环境变量可以修改 sys.path . PYTHONHOME 为python安装的前缀设置备用值。例如,如果 PYTHONHOME 设置为 /www/python ,搜索路径将设置为 ['', '/www/python/lib/pythonX.Y/', '/www/python/lib/pythonX.Y/plat-linux2', ...] .

这个 PYTHONPATH 变量可以设置为将添加到 sys.path . 例如,如果 PYTHONPATH 设置为 /www/python:/opt/py ,搜索路径将以开始 ['/www/python', '/opt/py'] . (请注意,目录必须存在才能添加到 sys.pathsite 模块删除不存在的路径。)

最后, sys.path 只是一个普通的python列表,所以任何python应用程序都可以通过添加或删除条目来修改它。

distutils配置文件

如上所述,您可以使用distuils配置文件记录任何distuils选项的个人或站点首选项。也就是说,任何命令的任何选项都可以存储在两个或三个(取决于您的平台)配置文件中的一个文件中,在解析命令行之前,将参考这些文件。这意味着配置文件将覆盖默认值,而命令行将反过来覆盖配置文件。此外,如果应用多个配置文件,“早期”文件中的值将被“后期”文件覆盖。

配置文件的位置和名称

配置文件的名称和位置在不同的平台上略有不同。在UNIX和Mac OS X上,三个配置文件(按处理顺序)是:

文件类型

位置和文件名

笔记

系统

prefix/lib/pythonver/distutils/distutils.cfg

(1)

个人的

$HOME/.pydistutils.cfg

(2)

地方的

setup.cfg

(3)

在Windows上,配置文件是:

文件类型

位置和文件名

笔记

系统

prefix\Lib\distutils\distutils.cfg

(4)

个人的

%HOME%\pydistutils.cfg

(5)

地方的

setup.cfg

(3)

在所有平台上,通过传递 --no-user-cfg 选择权。

笔记:

  1. 严格来说,系统范围的配置文件位于安装distutils的目录中;在python 1.6及更高版本的unix下,如图所示。对于python 1.5.2,distuils通常安装在 {prefix}/lib/python1.5/site-packages/distutils ,所以系统配置文件应该放在python 1.5.2下。

  2. 在UNIX上,如果 HOME 未定义环境变量,将使用 getpwuid() 标准中的功能 pwd 模块。这是由 os.path.expanduser() distutils使用的函数。

  3. 即,在当前目录中(通常是安装脚本的位置)。

  4. (另请参见注释(1)。)在python 1.6和更高版本下,python的默认“安装前缀”是 C:\Python ,因此系统配置文件通常 C:\Python\Lib\distutils\distutils.cfg .在python 1.5.2中,默认前缀是 C:\Program Files\Python 和distuils不是标准库的一部分,因此系统配置文件 C:\Program Files\Python\distutils\distutils.cfg 在Windows下的标准python 1.5.2安装中。

  5. 在Windows上,如果 HOME 未定义环境变量, USERPROFILE 然后 HOMEDRIVEHOMEPATH 将尝试。这是由 os.path.expanduser() distutils使用的函数。

配置文件的语法

distutils配置文件都具有相同的语法。配置文件分为多个部分。每个distutils命令有一个部分,加上 global 影响每个命令的全局选项的部分。每段每行包含一个选项,指定为 option=value .

例如,以下是一个完整的配置文件,默认情况下只强制所有命令安静运行:

[global]
verbose=0

如果将其安装为系统配置文件,它将影响当前系统上任何用户对任何python模块分发的所有处理。如果它安装为您的个人配置文件(在支持它们的系统上),它将只影响您处理的模块分发。如果它被用作 setup.cfg 对于特定的模块分发,它只影响该分发。

您可以重写默认的“build base”目录,并使 build* 命令始终使用以下命令强制重新生成所有文件:

[build]
build-base=blib
force=1

对应于命令行参数:

python setup.py build --build-base=blib --force

除此之外,包括 build 命令行上的命令意味着将运行该命令。在配置文件中包含一个特定的命令并没有这样的含义;它只意味着如果运行该命令,配置文件中的选项将应用。(或者,如果运行从中派生值的其他命令,则它们将使用配置文件中的值。)

您可以使用 --help 选项,例如:

python setup.py build --help

您可以使用 --help 没有命令:

python setup.py --help

另请参见“分布式Python模块”手册的“参考”部分。

构建扩展:提示和技巧

只要可能,distuils就会尝试使用运行 setup.py 脚本。例如,用于编译python的编译器和链接器标志也将用于编译扩展。通常这会很好地工作,但在复杂的情况下,这可能是不适当的。本节讨论如何重写通常的distuils行为。

调整编译器/链接器标志

编译用C或C++编写的Python扩展有时需要为编译器和链接器指定自定义标志,以便使用特定的库或产生一种特殊类型的对象代码。如果扩展没有在您的平台上进行测试,或者您正试图交叉编译Python,那么这一点尤其正确。

在最一般的情况下,扩展作者可能已经预见到编译扩展会很复杂,并且提供了一个 Setup 文件供您编辑。只有当模块分发包含多个独立的扩展模块时,或者它们通常需要精心设置的编译器标志集才能工作时,才可能完成此操作。

A Setup 文件(如果存在)将被解析,以便获得要生成的扩展名列表。A中的每一行 Setup 描述单个模块。行具有以下结构:

module ... [sourcefile ...] [cpparg ...] [library ...]

让我们依次检查每个字段。

  • 模块 是要生成的扩展模块的名称,并且应该是有效的Python标识符。您不能仅仅为了重命名一个模块而更改它(也需要对源代码进行编辑),所以应该将其单独保存。

  • 源文件 是任何可能是源代码文件的文件,至少根据文件名判断。文件名结尾为 .c 假定以c开头,文件名以 .C.cc.c++ 假设为C++,文件名终止于 .m.mm 假设在目标C中。

  • CPPARG 是C预处理器的参数,并且是以 -I-D-U-C .

  • 类库 有什么结尾吗 .a 或者从 -l-L .

如果特定平台需要平台上的特殊库,可以通过编辑 Setup 文件和运行 python setup.py build . 例如,如果由行定义的模块:

foo foomodule.c

必须与数学库链接 libm.a 在您的平台上,只需添加 -lm 到:

foo foomodule.c -lm

用于编译器或链接器的任意开关可以随 -Xcompiler arg-Xlinker arg 选项:

foo foomodule.c -Xcompiler -o32 -Xlinker -shared -lm

之后的下一个选项 -Xcompiler-Xlinker 将附加到适当的命令行,因此在上面的示例中,编译器将通过 -o32 选项,链接器将被传递 -shared . 如果编译器选项需要参数,则必须提供多个 -Xcompiler 选项;例如,传递 -x c++ 这个 Setup 文件必须包含 -Xcompiler -x -Xcompiler c++ .

也可以通过设置 CFLAGS 环境变量。如果设置,则 CFLAGS 将添加到 Setup 文件。

在Windows上使用非Microsoft编译器

Borland/CordEng+ C+

本节描述了使用Borland C++编译器版本5.5的ditudil的必要步骤。首先,您必须知道Borland的对象文件格式(OMF)与您可以从python或activestate网站下载的python版本所使用的格式不同。(Python是用微软Visual C++构建的,它使用COFF作为对象文件格式。)为此,您必须转换Python的库。 python25.lib 变成Borland格式。您可以这样做:

coff2omf python25.lib python25_bcpp.lib

这个 coff2omf 程序附带了Borland编译器。文件 python25.lib 是在 Libs python安装的目录。如果您的扩展使用其他库(zlib,…),那么您也必须转换它们。

转换后的文件必须与普通库位于同一目录中。

distuils如何使用这些更改了名称的库?如果扩展需要库(例如 foo )distutils首先检查是否找到带有后缀的库 _bcpp (例如) foo_bcpp.lib )然后使用这个库。如果它找不到这样一个特殊的库,它将使用默认名称 (foo.lib1

要让ditudil用Borland C++编译扩展,现在必须键入:

python setup.py build --compiler=bcpp

如果您想使用Borland C++编译器作为默认值,可以在个人或全系统配置文件中指定diditul(参见 distutils配置文件

参见

C++Builder Compiler

关于Borland的免费C++编译器的信息,包括下载页面的链接。

Creating Python Extensions Using Borland's Free Compiler

描述如何使用Borland的自由命令行C++编译器来构建Python的文档。

GNU C/Cygwin/Mingw公司

本节描述了在Gyc/C++编译器中使用dituTIL的必要步骤。 2 对于使用cygwin构建的python解释器,没有以下任何步骤,一切都可以工作。

不是所有的扩展都可以用mingw或cygwin构建,但是很多扩展可以。最可能不工作的扩展是使用C++或依赖于微软Visual C扩展的那些扩展。

要让distuils使用cygwin编译扩展,必须键入:

python setup.py build --compiler=cygwin

对于非cygwin模式下的cygwin 3 或Mingw型:

python setup.py build --compiler=mingw32

如果要将这些选项/编译器中的任何一个作为默认值,则应考虑将其写入distuils的个人或系统范围的配置文件(请参见第节 distutils配置文件

python和mingw的旧版本

以下说明仅适用于使用低于2.4.1、mingw低于3.0.0(使用binutils-2.13.90-20030111-1)的python版本的情况。

这些编译器需要一些特殊的库。这个任务比Borland的C++更复杂,因为没有程序来转换库。首先,您必须创建一个由python dll导出的符号列表。(您可以在https://sourceforge.net/projects/mingw/files/mingw/extension/pexports/上找到适合此任务的程序)。

pexports python25.dll >python25.def

安装的位置 python25.dll 将取决于安装选项以及Windows的版本和语言。在“只为我”安装中,它将显示在安装目录的根目录中。在共享安装中,它将位于系统目录中。

然后,您可以根据这些信息为gcc创建一个导入库。::

/cygwin/bin/dlltool --dllname python25.dll --def python25.def --output-lib libpython25.a

生成的库必须与 python25.lib . (应该是 libs python安装目录下的目录。)

如果您的扩展使用其他库(zlib,…),您可能也需要转换它们。转换后的文件必须与普通库位于同一目录中。

参见

Building Python modules on MS Windows platform with MinGW

有关为Mingw环境构建所需库的信息。

脚注

1

这也意味着您可以用同名的OMF库替换所有现有的COFF库。

2

有关详细信息,请访问https://www.sourceware.org/cygwin/和http://www.mingw.org/。

3

那么您就没有可用的POSIX仿真,但是您也不需要 cygwin1.dll .