Python与Javascript相互调用超详细讲解（四）使用PyNode进行Python与Node.js相互调用项（cai）目（keng）实（jing）践（yan）

• 2022 年 1 月 30 日
• 笔记
• Node.js, PyNode, Python, 开发

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`
  

  出现结果例如：

  # 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有动态库，那么PyNode的安装应该不会出现啥问题。

安装

首先，如果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'
}

根据StackOverflow上说，链接时能找到库是一回事，不代表它运行的时候也能找到，运行的时候查找动态库又有另一套路径（……）。

验证方法可以是：
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函数来手动打开动态链接。

1. 首先肯定是要找到你的动态库，可以使用上文所说的find_libpython包来查找。假设为：

   /opt/libpath/libpython3.9.so.1.0
   

2. 然后在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单元测试卡住不会结束

表现是：

1. 当测试文件多于cpu_count - 1的时候，整个测试程序卡住，不会再进行下一个test suite。
2. 如果使用--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的路径。