首页 > 解决方案 > cython 嵌入后的 ImportError

问题描述

我无法通过已编译的 python 脚本看到其他可用的模块。我需要如何更改以下流程才能接受基于 venv 的模块或全局模块?

脚步:

$ python3 -m venv sometest
$ cd sometest
$ . bin/activate
(sometest) $ pip3 install PyCrypto Cython

基本脚本,使用非标准模块Crypto

# hello.py
from Crypto.Cipher import AES
import base64
obj = AES.new('This is a key123', AES.MODE_CBC, 'This is an IV456')
msg = "The answer is no"
ciphertext = obj.encrypt(msg)
print(msg)
print(base64.b64encode(ciphertext))
(sometest) $ python3 hello.py
The answer is no
b'1oONZCFWVJKqYEEF4JuL8Q=='

编译它:

(sometest) $ cython -3 --embed hello.py
(sometest) $ gcc -Os -I /usr/include/python3.5m -o hello hello.c -lpython3.5m -lpthread -lm -lutil -ldl
(sometest) $ $ ./hello
Traceback (most recent call last):
  File "hello.py", line 1, in init hello
    from Crypto.Cipher import AES
ImportError: No module named 'Crypto'

我认为使用 cython 嵌入编译脚本中的 venv 不是问题:该脚本可以在没有 venv 的系统中的其他地方工作(也就是说,python3 -c 'from Crypto.Cipher import AES'不会失败)。

否则,该过程可以正常工作:

(sometest) $ echo 'print("hello world")' > hello2.py
(sometest) $ cython -3 --embed hello2.py
(sometest) $ gcc -Os -I /usr/include/python3.5m -o hello2 hello2.c -lpython3.5m -lpthread -lm -lutil -ldl
(sometest) $ ./hello2
hello world

系统:

(sometest) $ python3 --version
Python 3.5.2
(sometest) $ pip3 freeze
Cython==0.29.11
pkg-resources==0.0.0
pycrypto==2.6.1

(sometest) $ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.6 LTS"

标签: pythonmodulecython

解决方案


通常,Python 解释器不是“独立的”,为了工作,它需要其标准库(例如ctypes(编译)或(解释)),并且还必须设置site.py其他站点包的路径(例如)。numpy

尽管可以通过冻结 py-modules 并将所有 c-extensions(例如参见此 SO-post)合并到生成的可执行文件中来使 Python-interpter 完全独立,但为嵌入式解释器提供所需的安装更容易. 可以从 python-homepage 下载“标准”安装所需的文件(至少对于windows),另请参见此SO-question)。

有时找到标准模块/站点包并不能开箱即用:必须通过设置 Python-path 来帮助解释器,即通过在 pyx 文件中以编程方式添加<..>/sometest/lib/python3.5/site-packagessometest作为虚拟环境根文件夹)sys.path或通过在开始之前设置PYTHONPATH-environment 变量。

继续阅读以了解更多血腥细节和替代解决方案。


此答案适用于 Linux 和 Python3(Python 3.7),基本思想与 Windows/MacOS 相同,但某些细节可能有所不同。

因为venv使用了我们有以下替代方案来解决这个问题:

  • 以编程方式在 pyx 文件中添加<..>/sometest/lib/python3.5/site-packagessometest作为虚拟环境根文件夹)sys.pathPYTHONPATH在启动之前设置 -environment 变量。
  • 将嵌入了python的可执行文件放在sometest(例如bin或创建自己的)的子目录中。
  • 使用virtualenv而不是venv.

注意:对于嵌入了python的可执行文件,无论是否激活虚拟环境(或哪个)都没有任何作用。


为什么以上解决了您的方案中的问题?

问题是,(嵌入式)Python 解释器需要弄清楚以下内容在哪里:

  • 与平台无关的目录/文件,例如os.pyargparse.py(大部分都是 *.py/ *.pyc)。给定sys.prefix,解释器可以找出在哪里可以找到它们(即在 中prefix/lib/pythonX.Y)。
  • 平台相关目录/文件,例如共享库。假设sys.exec_prefix解释器可以找出在哪里可以找到它们(例如,可以在 中找到共享库exec_prefix/lib/pythonX.Y/lib-dynload)。

该算法可以在这里找到并执行搜索,何时Py_Initialize执行。一旦找到这些目录,sys.path就可以构建。

但是,在使用时, exe 旁边或父目录中venv有一个pyvenv.cfg-file ,可确保找到正确的 Python-Home - 一个很好的起点是此文件中的 -key。home

如果Py_NoSiteFlag未设置,Py_Initialize将利用site.py(它可以被解释器发现,因为sys.prefix已知),或者更准确地说site.main(),将虚拟环境的站点包添加到sys.path. 这样做时,site.py查找pyvenv.cfg并解析它。但是,只有在以下情况下才会将 localsite-packages添加到 python-path:

如果名为“pyvenv.cfg”的文件存在于 sys.executable 上方的一个目录中,则 sys.prefix 和 sys.exec_prefix 将设置为该目录,并且还会检查站点包(sys.base_prefix 和 sys.base_exec_prefix 将始终是Python 安装的“真实”前缀)。

在您的情况下pyvenv.cfg,它不在上面的目录中,但与 exe 相同 - 因此不包括通过 pip 安装库的本地站点包。全局站点包不包括在内,因为pyvenv.cfg有 key include-system-site-packages = false。因此,不允许使用站点包,并且无法找到已安装的库。

但是,将 exe 向下移动一个目录会导致将本地站点包包含到路径中。


还有其他可能的情况,重要的是可执行文件的位置,而不是激活的环境。

A:可执行文件在某处,但不在虚拟环境中

这种搜索启发式对已安装的 python 解释器或多或少可靠,但可能适用于嵌入式解释器或虚拟环境(有关更多信息,请参阅此问题)。

如果使用通常的或类似的方式安装了 python apt install,那么它将被找到(由于搜索算法中的4. 步骤),并且嵌入式解释器将使用系统安装。

但是,如果文件被移动或 python 是从源代码构建但未安装,则嵌入的 interperter 无法启动:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: initfsencoding: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

在这种情况下,Py_SetPythonHome或设置环境变量$PYTHONHOME是可能的解决方案。

B:在虚拟环境中可执行,使用 virtualenv 创建

假设虚拟环境和嵌入式 python 的 Python 版本相同(否则我们有上述情况),嵌入式 exe 将使用本地侧包。由于这条规则,家庭搜索算法总是会找到本地家庭:

步骤 3. 尝试找到相对于 argv0_path 的前缀和 exec_prefix,回溯路径直到用尽。这是成功的最常见步骤。注意,如果 prefix 和 exec_prefix 不同,exec_prefix 更有可能被找到;但是,如果 exec_prefix 是前缀的子目录,则会找到两者。

在这种情况下 argv0_path是 exe 的路径(没有pyvenv.cfg文件!),并且会找到“地标”(lib/python$VERSION/os.py 和 lib/python$VERSION/lib-dynload),因为它们是在 exe 上方的本地主页中显示为符号链接。

venvC: -environment深处的可执行两个文件夹

venv在一个-environment 中pyvenv.cfg去两个而不是一个文件夹(它工作的地方)会导致以下情况侧包存在),这样的第 3 步将失败,第 4 步是唯一的希望。


推论:如果没有正确的 Python 安装,嵌入式 Python 将无法工作,除非有其他可能性:

  • 所需的文件被打包到lib\pythonX.Y\*嵌入可执行文件旁边或上面的某个地方(并且没有任何pyvenv.cfg地方可以搞乱搜索)。

  • pyvenv.cfg用于将解释器指向正确的位置。


推荐阅读