PyNode是一个轻量级的Node.js C++扩展包,使用Node.js的N-API写成的,能在同一个进程里通过底层C/C++的API实现python和javascript的互操作,只需要进行数据类型的转换,运行效率高。详细的原理讲解可以看我这篇介绍。
本文主要简单记录一下使用PyNode的一些实践经验。
前提
安装的前提是装好两种语言的runtime。
- Node.js:没啥特别的,直接装就行了。
Linux系统安装Node.js可以直接用NVM(Node Version Manager),与python的conda类似。
- Python:由于PyNode是在Node.js的C++扩展里嵌入了python,因此需要Python的动态/静态库。
一般情况下,cpython官方给的安装版都是由一个动态库(比如在Linux里会叫:libpython3.x.so
),和一个依赖该库的小可执行文件组成。这样非常方便其它C++程序嵌入python。
这种Python通常是通过--enable-shared
选项编译安装的,可以在你的python环境里运行:
这个返回import sysconfig sysconfig.get_config_vars('Py_ENABLE_SHARED')
[1]
就是true,[0]
就是false。true
代表着是通过--enable-shared
选项编译安装的。
还有一种更本质的方法,直接看可执行文件依赖的动态库。Linux上可以通过ldd
命令,Mac OS上可以通过otools -L
命令,查看你的python可执行文件的依赖情况:
出现结果例如:# If your python command is "python3", use `which python3` # On Linux: ldd `which python` # On Mac OS otools -L `which python`
说明你的python有动态库,那么PyNode的安装应该不会出现啥问题。# On Linux root@7fe6daacb730:/# ldd `which python` linux-vdso.so.1 (0x00007ffe41b47000) libpython3.9.so.1.0 => /usr/local/lib/libpython3.9.so.1.0 (0x00007fd5feb2c000) # python library libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fd5feaf2000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd5fead1000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd5feacc000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fd5feac7000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fd5fe944000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5fe781000) /lib64/ld-linux-x86-64.so.2 (0x00007fd5fef08000) # On Mac OS /your/python/executable/dir/venv/bin/python: /Library/Frameworks/Python.framework/Versions/3.9/Python (compatibility version 3.9.0, current version 3.9.0) # Depends on python shared library /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.0.0)
安装
首先,如果python库没啥问题,按项目简介所说,安装前首先确认好你需要使用的python环境,如果要用虚拟环境,也先进入虚拟环境。
# Install gyp-next
pip install gyp-next
# Install PyNode
npm install @fridgerator/pynode
# or
yarn add @fridgerator/pynode
那么,如果你的python不依赖动态库咋办呢?如果你是Conda环境,那么还是有可能找到动态库的:
找到你的Python动态库
适用于Conda环境。一些详细的log可以参考这个Issue。下面的介绍跟我在这个Issue里的comment基本一样的。
如果你用的是Conda环境,恭喜你,他们提供的python,旧一点的,可能会遇到GCC版本低问题,而新一点的,已经直接用静态库build成可执行文件了,再也不依赖动态库了:
(py38) $ ldd `which python`
linux-vdso.so.1 (0x00007ffe03efd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007faa187be000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007faa185bb000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007faa1821d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007faa17ffe000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007faa17c0d000)
/lib64/ld-linux-x86-64.so.2 (0x00007faa18d5d000)
不过好消息是,Conda声称他们尽管不用,但还是提供了动态库,所以我们只要找到它就可以了。有一个很好用的python包find_libpython
,能很好地找到你的python动态库:
(py38) $ pip install find_libpython
(py38) $ find_libpython # or "python -m find_libpython" /xxx/miniconda3/envs/py38/lib/libpython3.8.so.1.0.
然后我们要做的就是把动态库的目录路径作为库路径添加到PY_LIBS
里(-L
)。
但这样做链接的时候能找到库,后面执行的时候也还是会找不到,一种解决方法是用rpath把这个路径给他刻烟吸肺,运行的时候也能找到(通过-Wl,-rpath=
)。那么加在一起,你的包安装命令就应该是:
PYTHON_SHARED=/xxx/miniconda3/lib PY_LIBS="$(python ../build_ldflags.py) -L$PYTHON_SHARED -Wl,-rpath=$PYTHON_SHARED" npm install @fridgerator/pynode
使用
没啥好说的,使用起来很简单,按项目首页的Readme做就可以了。列一些使用Tips和可能出问题的地方。
const pynode = require('@fridgerator/pynode')
的时候动态链接错误
Uncaught:
Error: libpython3.9.so.1.0: cannot open shared object file: No such file or directory
at Object.Module._extensions..node (node:internal/modules/cjs/loader:1168:18)
at Module.load (node:internal/modules/cjs/loader:989:32)
at Function.Module._load (node:internal/modules/cjs/loader:829:14)
at Module.require (node:internal/modules/cjs/loader:1013:19)
at require (node:internal/modules/cjs/helpers:93:18) {
code: 'ERR_DLOPEN_FAILED'
}
根据*上说,链接时能找到库是一回事,不代表它运行的时候也能找到,运行的时候查找动态库又有另一套路径(……)。
验证方法可以是:
cd进入node_modules/@fri/x/build/Release
里,会找到编译好的PyNode.node
然后,ldd PyNode.node
linux-vdso.so.1 (0x00007ffef7de3000) libpython3.9.so.1.0 => not found # Failed to find when executing libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f976bd9c000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f976ba13000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f976b7fb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f976b40a000) /lib64/ld-linux-x86-64.so.2 (0x00007f976c1bd000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f976b06c000)
就是说,build的时候提供-lpython3.9
和-L<path_to_shared_library>
是明确指定好库,这样生成的文件PyNode.node
才包含这个库,换句话说,它才会出现在ldd的list里。
但这个可执行文件运行的时候找共享库,跟build的时候提供的路径没有关系,感觉它像是会在一个给定的路径集合里找,所以这些路径集合里没有libpython3.9.so.1.0
,那ldd就会显示not found。
在linux下,一种解决方案是通过往环境变量LD_LIBRARY_PATH
里添加这个动态库的目录,例如:如果动态库的绝对路径为/opt/libpath/libpython3.9.so.1.0
,那么可以在~/.bashrc
里添加一行:
export LD_LIBRARY_PATH="/opt/libpath:$LD_LIBRARY_PATH"
这之后再ldd .node
文件,就能找到了:
linux-vdso.so.1 (0x00007ffc01562000)
libpython3.9.so.1.0 => /opt/libpath/libpython3.9.so.1.0 (0x00007f041a327000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f041a123000)
libstdc++.so.6 => /mnt/asp_test/env/miniconda3/lib/libstdc++.so.6 (0x00007f041a9be000)
libgcc_s.so.1 => /mnt/asp_test/env/miniconda3/lib/libgcc_s.so.1 (0x00007f041a9aa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0419d32000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f0419b2f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0419791000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0419572000)
/lib64/ld-linux-x86-64.so.2 (0x00007f041a91d000)
另一种方法是用rpath,就像上面针对Conda环境安装的那样,把动态库的路径同时也加到-Wl,-rpath=
里。
ImportError: math.cpython-39-x86_64-linux-gnu.so: undefined symbol: PyFloat_Type
或者类似undefined symbol: PyExc_ValueError
和undefined symbol: PyExc_SystemError
的错误。
通常会在Linux上出现,属于是打开动态链接的时候出了问题。PyNode提供了一个dlOpen
函数来手动打开动态链接。
- 首先肯定是要找到你的动态库,可以使用上文所说的
find_libpython
包来查找。假设为:/opt/libpath/libpython3.9.so.1.0
- 然后在Node.js里:
const pynode = require('@fridgerator/pynode'); pynode.dlOpen('/opt/libpath/libpython3.9.so.1.0');
在Node.js里运行Python的multiprocessing
Node.js通过C API起了一个python解释器,这种情况下本进程的可执行程序其实是node
。换句话说,sys.argv[0]
,sys.executable
都是指向node的可执行程序。
而python环境中开新的多进程同时运行,会获取当前的可执行程序(excutable),发现竟然不是python
,那multiprocessing
就读不懂这个可执行程序的信息,比如说找不到main
从而报错。
查看源代码后发现了multiprocessing.spawn
里的这么一段:
有一个接口set_executable
,可以重新设置可执行程序。所以通过PyNode去调用使用了multiprocessing
的python程序可以这么做:重新设置executable为你的python可执行程序。
比如,我用了virtualenv,我的可执行程序就是:/my/project/path/venv/bin/python
const pynode = require('@fridgerator/pynode');
pynode.startInterpreter();
const sp = pynode.import('multiprocessing.spawn');
sp.get('set_executable').call('/my/project/path/venv/bin/python');
// Run the multiprocessing python code
需要注意的是,这种补丁操作只适用于纯Python的multiprocessing。如果你的某个子进程混入了一些node.js的代码,那么会报错。还没搞懂具体原理,我猜想原因可能是,子进程是通过python可执行程序起的,找不到node环境。
Jest单元测试卡住不会结束
表现是:
- 当测试文件多于
cpu_count - 1
的时候,整个测试程序卡住,不会再进行下一个test suite。 - 如果使用
--runInBand
选项禁止多线程执行单元测试,会Segment Fault
。
起因是segment fault了,而Jest不知道为啥在多线程跑单元测试的时候(一般一个文件一个线程,开线程的数量是cpu_count - 1
),在某些OS里遇到segment fault当前线程就会卡死,所以总共会坚持cpu_count - 1
个test suite,然后才卡死。如果文件数据少于cpu_count - 1
的话,会顺利运行完。
经过研究,segment fault的原因是:StartInterpreter
不可以重复调用2次,因为它里面有一个函数执行的时候需要Python的全局进程锁(GIL),但StartInterpreter
在第二次调用的时候不调用Py_Initialize
,因此也不重新获取GIL,导致segment fault了。
而Jest的每个测试的环境都是全新的,不管是把const pynode = require('@fridgerator/pynode');
放到单独一个文件里require
,还是用一个全局变量标记是否已经start Interpreter都无法阻止StartInterpreter
被调用2次导致segment fault。
解决办法就是不用Jest 修改源码,不管怎样在调用那个函数前都获取一下GIL(PR)。
这个PR还没被merge进pynoe的版本,想安装这个版本的话,可以下载我fork的repo里的源码。
然后在项目根目录里npm pack
,会得到一个.tgz
文件,然后在package.json
里这么写:
"dependencies": {
"@fridgerator/pynode": "file:./pynode/fridgerator-pynode-0.5.2.tgz"
},
路径就是你的这个文件相对于package.json
的路径。