★ FEATURED ARTICLE 简介这是一份面向Linux运维及Python开发者的Python 3.6.5离线安装包专门解决内网或无法访问PyPI环境下安装Python及常用库的痛点。压缩包共2000个文件体积158.82MB内部以pyc/py源码、so动态库、头文件及Django模板为主涵盖科学计算、数据库驱动、Web框架等二十余个常用组件。包内已集成numpy、pandas、tensorflow、Django、djangorestframework、SQLAlchemy、PyMySQL、elasticsearch等库解压后即可快速启用省去逐个安装依赖的繁琐过程。该安装包已在CentOS6.5、CentOS7、RedHat上验证运行适合AI/机器学习、Web服务开发及离线环境搭建场景。截至目前已有4153人学习下载可作为内网环境部署Python生产环境的可靠基础资源。1. 给内网 AI/ML 环境装 Python 3.6.5离线安装包到底解决什么问题AI 和机器学习项目跑起来之前最磨人的往往不是模型调参而是先把 Python 环境在目标机器上立住。很多生产服务器是内网隔离的既没有外网权限也装不了 apt 源里现成的包这时候一个完整的 Python 3.6.5 Linux 离线安装包就是救命的东西。它解决的是一整条环境链路解释器、核心依赖、编译工具、pip 离线安装能力而不是简单地拷一个压缩包过去解压。这篇文章从安装包的选型逻辑、编译安装步骤、依赖坑位一直讲到离线虚拟环境的验证方法给新手一条能照着走的路也给熟手标出容易翻车的边界。2. 离线安装的底层逻辑为什么 Python 3.6.5 还是 AI/ML 场景的常见选择2.1 离线安装包不只是“解压即用”的二进制文件很多初学者拿到离线安装包时第一反应是“这应该跟 Windows 安装包一样双击就能用”但在 Linux 上尤其在内网服务器上事情要细得多。常见的离线安装包有两种形态一种是官方发布的源码包python-3.6.5.tgz需要先 configure、make、make install 编译安装另一种是某个发行版仓库打好的 rpm 包或 deb 包依赖系统自带的库装起来相对快但受发行版版本限制。我一般会优先选择源码包原因是可控性最强。编译安装时你可以决定安装前缀默认是 /usr/local可以显式指定 openssl、readline、zlib 等依赖库的路径还能通过 configure 参数把不需要的模块裁掉。对于内网环境来说源码包还有一个优势——它不依赖系统的包管理器版本只要编译工具链不缺红帽系的 CentOS 和 Debian 系的 Ubuntu 都能装。2.2 Python 3.6.5 在 ML 依赖栈里的位置有些人会问现在 Python 都到 3.12 了为什么还要用 3.6.5答案往往不是“新版本不好”而是很多老的 AI/ML 项目依赖的第三方库版本是用 3.6 时代编译的。比如 tensorflow 1.x 的某些内部版本、pytorch 早期版本、一些自定义的 Cython 扩展模块它们编译时绑定了 CPython 的 ABI应用二进制接口。如果强行用 3.8 或更高版本的 Python 去跑要么 import 阶段直接崩要么编译时出现 undefined symbol 的错误。还有一个现实原因是很多内网机器操作系统本身是 CentOS 7 这类老系统系统的 glibc 版本停留在 2.17高版本 Python 对 glibc 的要求更高跑起来反而有兼容性风险。所以在选型的时候先确认项目依赖的 tf 或 torch 版本再回头定 Python 版本。3.6.5 对应的常见组合是 tensorflow 1.14/1.15、torch 1.1 到 1.4、opencv-python 4.1.x这些组合在离线环境里经过大量生产验证坑位比较透明。如果你跑的是新模型用 Python 3.8 更合适但如果核心依赖是老的回到 3.6.5 反而是最省事的路径。2.3 离线环境的依赖闭环解释器、pip、wheel 三件套离线安装要一次到位需要想清楚三件事解释器本身、pip 工具链、以及预下载好的第三方包。只装好 Python 解释器没用因为内网机器没有外网pip install 默认从官方源走不通所以离线安装包里必须连带解决 pip 离线安装渠道。常见做法是下载 wheel 文件到本地目录然后用pip install --no-index --find-links指向本地目录。这里的关键点是Python 3.6.5 自带的 pip 版本通常是 9.x 或 10.x比较老对 wheel 格式的支持没问题但解析依赖的能力弱遇到依赖树复杂的包容易乱套。我一般会在装完 Python 后立刻用离线 wheel 升级 pip 到 20.x 或 21.x这一步虽然不显眼却能避免后面大量“pkg_resources 找不到”的玄学问题。环境要素作用常见问题解释器python3.6运行 Python 字节码与 C 扩展编译失败往往缺系统库pip升级到 20.x解析依赖、安装 wheel老版本 pip 对依赖树解析不完整本地 wheel 目录作为离线包索引来源缺少依赖导致安装中断3. 下载与准备编译前你要检查的四个关键点3.1 校验安装包完整性哈希和内容检查拿到离线安装包后不要急着解压。先做两件事校验哈希值和检查目录结构。哈希校验能确认压缩包在传输过程中没损坏尤其在从移动硬盘或文件服务器拷贝的场景下文件损坏的概率比你想象的高。操作很简单# 校验 SHA256输出的值必须与官方或资源方提供的哈希一致 sha256sum Python-3.6.5.tgz # 解压前查看包内文件列表确认包含 Modules/、Lib/、configure 等关键内容 tar -tzf Python-3.6.5.tgz | head -n 20逻辑说明第一行命令计算压缩包的 SHA256 值用于和资源方给出的官方哈希做比对。第二行列出压缩包内的顶层目录结构排查是否存在文件缺失或空目录。参数说明-t表示只列出文件不展开-z表示通过 gzip 解压读取head -n 20只显示前 20 行够看清结构。3.2 编译工具链检查gcc、make、openssl 缺一不可源码包的方式意味着机器上必须有 C 编译器。用一个命令检查关键工具是否具备# 检查 gcc 与 make 是否可用 gcc --version make --version # 检查 openssl 开发头文件是否存在缺少它后面 pip 会出问题 ls /usr/include/openssl/ssl.h逻辑说明前两行确认编译器和 make 工具链版本版本过低gcc 4.4 以下编译 3.6.5 的某些模块会失败。最后一行检查 openssl 开发头文件Python 的 ssl 模块编译时需要它如果缺失装出来的 Python 可以跑但 pip 无法访问 HTTPS 源。参数说明/usr/include/openssl/ssl.h是 Red Hat 系的默认路径Debian 系通常在/usr/include/openssl/ssl.h或/usr/lib/x86_64-linux-gnu/openssl下找不到时用find /usr -name ssl.h定位。3.3 依赖库齐备性zlib、readline、bzip2 的作用编译 Python 过程中有三个库缺一不可zlib、readline、bzip2。zlib 缺失会导致make阶段报错zipimport.ZipImportError因为 Python 的模块导入机制依赖 zlib 解压readline 缺失会导致交互式命令行方向键和补全失效bzip2 缺失会导致bz2模块编译失败虽然不影响基本使用但某些 pip 包比如 pandas 的低版本在 import 时会调用 bz2。检查命令# 缺什么补什么常用系统包管理器安装 # Red Hat 系 sudo yum install zlib-devel readline-devel bzip2-devel openssl-devel # Debian 系 sudo apt-get install zlib1g-dev readline-dev libbz2-dev libssl-dev逻辑说明开发版头文件-devel后缀比运行时库更重要Python 编译时找的是.h文件而非.so文件。参数说明Red Hat 系和 Debian 系的包名有差异同名包在不同系列里可能叫readline-dev而不是readline-devel装之前先用yum list或apt-cache search确认包名。3.4 安装目录规划避免污染系统自带 Python我见过不少翻车案例直接把 Python 3.6.5 编译安装覆盖了系统自带的 Python 2.7结果 yum 直接挂掉。正确做法是指定独立的安装前缀比如/usr/local/python365或/opt/python365# 编译前规划安装目录 mkdir -p /opt/python365逻辑说明单独目录的好处不只是安全后续卸载也干净删掉整个目录就行。运维上还能用软链接或环境变量把 3.6.5 暴露给特定项目。参数说明/opt是第三方软件的传统安装位置权限管理上建议用专门的技术账号拥有该目录避免 root 误操作。4. 编译安装与验证从 configure 到 import 全流程4.1 configure 参数设定哪些要开、哪些要关进入解压后的目录开始配置。安装参数不是随便执行的有几个关键的参数会直接决定后续 pip 和机器学习依赖能否顺利安装# 解压并进入源码目录 tar -xvzf Python-3.6.5.tgz cd Python-3.6.5 # configure指定安装目录、启用优化、显式链接系统和本地依赖 ./configure --prefix/opt/python365 \ --with-ssl \ --enable-optimizations \ --with-system-expat \ --with-system-ffi逻辑说明--prefix指定最终安装位置--with-ssl启用 ssl 模块支持--enable-optimizations会让 Python 做 PGO 优化代价是编译时间翻倍但解释器跑模型运算时的性能提升值得等待--with-system-expat和--with-system-ffi是用系统自带的 expat 和 ffi 库避免 Python 自带的旧版本引发冲突。参数说明--enable-optimizations在低配服务器上可能从 10 分钟变成 40 分钟着急的话可先用普通模式编译后续再单独做优化但不建议跳过尤其跑 AI 推理任务时。4.2 make 与 make install 的执行逻辑configure 成功后会生成 Makefile接下来编译。这里有一个常见误区直接make make install一把梭。如果编译中途报错日志会刷过去根本来不及看。我一般会分两步# 先编译生成可执行文件不安装 make -j4 # 再安装把编译好的文件放入 prefix 目录 make install逻辑说明-j4表示 4 个并行编译任务前提是机器有 4 核以上小内存机器建议-j1或-j2否则内存不足直接 OOM。参数说明编译阶段产物是./python可执行文件不要跳过 make 直接 make install因为 install 阶段不会重新编译如果源码有问题安装进去的还是坏文件。看到Could not build the ssl module的告警一定要停下排查这个告警说明 openssl 路径不对或者缺少头文件。4.3 安装后的路径配置与软链接安装完成后需要让 shell 找到新 Python。这里不要用硬链接覆盖系统路径改用户的 PATH 是更稳的做法# 把 Python 3.6.5 的 bin 目录追加到 PATH export PATH/opt/python365/bin:$PATH # 让配置永久生效写入当前用户的环境配置 echo export PATH/opt/python365/bin:$PATH ~/.bashrc source ~/.bashrc逻辑说明这两行命令把 Python 3.6.5 的 bin 目录放到 PATH 最前面后续python3和pip3指向的都是新装版本。参数说明是追加而不是覆盖避免误删已有 PATH 配置source ~/.bashrc让改动立刻生效不必退出重登。注意不要在/usr/bin下创建指向这个版本的软链接——系统自带的脚本可能依赖旧版 Python用到时会被切换掉。4.4 核心验证解释器、pip、关键模块三连检安装完不能直接说“大功告成”。我会依次验证三件事解释器版本、pip 版本、ssl 模块能否正常工作# 验证解释器版本与路径 which python3 python3 --version # 验证 pip 与 setuptools python3 -m pip --version # 验证 ssl 和 zlib 模块可导入 python3 -c import ssl; print(ssl.OPENSSL_VERSION) python3 -c import zlib; print(zlib.ZLIB_VERSION)逻辑说明which python3确认 PATH 优先指向的是 /opt/python365 下的版本而不是系统自带的导入 ssl 和 zlib 是为了确认刚才的 configure 参数真正生效这一步能拦截很多表面编译成功、实际模块缺失的情况。参数说明如果 ssl 导入失败不要再往下装任何第三方包回头检查 openssl-devel 是否安装、--with-ssl是否写对。5. 离线环境避坑指南六个高频翻车点与处理手段5.1 现象pip install 联网失败报 “Could not find a version”内网机器上执行pip install numpy报错信息是“Retrying…… Could not find a version that satisfies the requirement”。原因很直接pip 默认从公网源拉取内网根本连不上所以没有任何可用版本。解决手段是预先在能联网的机器上下载好 wheel 文件拷贝到内网本地指定索引安装# 在有外网的机器上按目标 Python 版本下载 numpy 及其依赖到目录 pip3.6 download numpy1.19.5 -d /tmp/packages/ # 在内网目标机器上从本地目录安装不访问网络 python3.6 -m pip install --no-index --find-links/tmp/packages numpy逻辑说明第一行命令在可联网的机器上把 numpy 1.19.5 自身的 wheel 和所有依赖项的 wheel 都下载到/tmp/packages/第二行命令中的--no-index禁用 pip 的公共索引--find-links让它只看本地目录。参数说明下载阶段最好用与目标机器相同的 Python 版本执行避免下到其他 CPython 版本的 wheel尤其是在 Windows 上下的包不能直接用于 Linux必须确认文件名中的linux_x86_64后缀。5.2 现象make 阶段报错 “zipimport.ZipImportError: can‘t decompress data”编译到一半突然看到这个报错第一反应以为是压缩包坏了重下了一遍还是一样。原因几乎可以锁定是 zlib 开发库缺失。Python 的模块打包机制依赖 zlib 解压.pyz和标准库的压缩模块系统里没有 zlib-devel 时编译出的 Python 在构建标准库时就会卡住。解决方式是先装 zlib 开发头文件再重新执行 configure 和 make# 安装 zlib 开发库Red Hat 系示例 sudo yum install zlib-devel # 重新从 configure 开始走确保新的头文件被检测到 make clean ./configure --prefix/opt/python365 --with-ssl make -j4 make install逻辑说明make clean清掉上次的编译中间产物否则可能继续沿用旧的配置缓存。参数说明有的人为了省时间直接跳过 configure 重新 make结果 Makefile 里根本没记录新的头文件路径问题依旧。重新执行 configure 是必要动作不是可选项。5.3 现象import ssl 报错 “No module named ‘_ssl’”解压安装包后Python 能启动但跑import ssl直接 ModuleNotFoundError。原因大概率是编译时 configure 没有找到 openssl 的头文件。这可能有两种情况一是系统没装 openssl-devel二是安装了但路径不在默认搜索范围内。解决方式先检查头文件再带着显式路径重新编译# 定位 openssl 的安装位置 find /usr -name ssl.h 2/dev/null # 在 configure 阶段显式指定 openssl 路径 ./configure --prefix/opt/python365 --with-ssl/usr make clean make -j4 make install逻辑说明--with-ssl/usr告诉 configure 到/usr/include下找 openssl 头文件这适用于大部分系统。参数说明如果 openssl 是从源码安装到/usr/local/ssl的这个参数要改成对应的路径。有些老系统的 openssl 版本是 1.0.2Python 3.6.5 能兼容但运行时如果内网要求更高安全等级可能需要升级系统 openssl这一步属于系统维护范畴不在本次安装范围内。5.4 现象pip install 到一半报 “TypeError: ‘module’ object is not callable”用系统自带的 pip 9.x 离线安装某些较新的 wheel 包时报一个很奇怪的类型错误。原因基本是旧版 pip 在解析新格式 wheel 元数据时不兼容。Python 3.6.5 自带的 pip 在ensurepip时安装的是配套版本相对较老对 2021 年以后打的 wheel 包支持不完整。解决方式是先升级 pip再进行后续安装# 提前准备好新版 pip 的 wheel 文件 python3.6 -m pip install --no-index --find-links/tmp/packages --upgrade pip # 验证升级后的版本 python3.6 -m pip --version逻辑说明升级 pip 本身也是一个离线安装操作同样依赖本地 wheel 目录。参数说明--upgrade参数让 pip 在已安装版本低于目标版本时执行升级。升级后 pip 的依赖解析能力明显增强很多“玄学”报错会自然消失。5.5 现象import numpy 报 “Illegal instruction (core dumped)”Python 装好后装 numpy一 import 就崩还出现 “Illegal instruction”。这个现象曾经让我排查了很久最后发现是 CPU 指令集的问题。原因pip 官方源上的 numpy 1.19 等版本带上了较新的 CPU 指令优化如 AVX512而内网服务器的 CPU 较老或不支持这些指令。解决方式有两个方向一是指定更老的兼容版本二是从源码编译 numpy# 优先尝试兼容版本比如 numpy 1.16.6 通常对老 CPU 更友好 python3.6 -m pip install --no-index --find-links/tmp/packages numpy1.16.6 # 如果依然崩溃退到源码编译方式 python3.6 -m pip install --no-index --find-links/tmp/packages numpy --no-binary numpy逻辑说明第一行安装一个更老的 numpy 版本其预编译 wheel 使用的指令集更保守第二行的--no-binary numpy强制 pip 从源码包编译能保证和当前 CPU 完全兼容。参数说明源码编译需要系统有 gcc 和 fortran 编译器否则会报缺工具链。测试 Python 的时候建议用python3.6 -c import numpy; print(numpy.__version__)而不是进入交互式环境便于持续观察崩溃信息。5.6 现象sci-kit 系列部分模块 import 失败报错指向 “libgomp.so.1: cannot open shared object file”装了一堆 AI 相关的包结果 import 某个 C 扩展模块时提示找不到共享库。原因很多科学计算包编译时依赖 OpenMP 运行时库libgomp而最小化的内网系统没装这个运行时。解决方式是补装系统库或者把库目录加入 LD_LIBRARY_PATH# 检查系统是否已有 libgomp ldconfig -p | grep libgomp # 没有就安装Red Hat 系 sudo yum install libgomp # Debian 系 sudo apt-get install libgomp1逻辑说明ldconfig -p列出当前系统可用的动态库缓存grep 过滤出 libgomp 相关信息。参数说明如果系统确实不存在这个库安装后再重新启动 Python 进程动态链接器就能正常找到它。注意安装后当前 shell 已打开的 Python 进程需要退出重进才会加载新库。6. 离线环境的联网验证pip 安装完一定要做的三步检查离线环境装完 Python 和第三方包之后最怕的是“表面能 import实际跑任务时崩”。我自己的习惯是做一个三重验证先验证隔离的虚拟环境、再验证关键依赖链、最后跑一次真实训练或推理小样例。第一步创建虚拟环境并安装核心包。直接用系统 Python 管理多个项目的依赖会互相污染尤其离线环境下纠正成本极高。用venv隔离是好习惯# 创建基于 Python 3.6.5 的虚拟环境并激活 /opt/python365/bin/python3.6 -m venv /opt/project_venv source /opt/project_venv/bin/activate # 在虚拟环境中验证解释器路径 which python3.6 python3.6 --version逻辑说明venv模块会基于当前解释器创建一套隔离的环境后续 pip 安装的包都只进这个环境。参数说明project_venv是环境目录名建议按项目命名便于多项目并存时快速定位。激活命令会改变当前 shell 的 PATH退出环境用deactivate。第二步验证 AI/ML 核心依赖链。写一段小脚本把 numpy、scipy、sklearn、pandas 全部导入一遍任何一环断裂都会在这里暴露# check_ml_stack.py import numpy import scipy import sklearn import pandas print(numpy version:, numpy.__version__) print(scipy version:, scipy.__version__) print(pandas version:, pandas.__version__) print(sklearn version:, sklearn.__version__)逻辑说明这个脚本检查的是容器类依赖的导入链路任何一个包编译时缺库都会在 import 阶段直接报错。参数说明numpy.__version__这种带双下划线的属性是包内置的版本常量打印出来的版本号要和项目要求的约束一致。第三步跑一个真实的小样例。拿 sklearn 自带的数据集做一次回归训练这是最接近生产环境的一次验证# smoke_test.py from sklearn.datasets import load_boston from sklearn.linear_model import LinearRegression from sklearn.model_selection import train_test_split data load_boston() X_train, X_test, y_train, y_test train_test_split( data.data, data.target, test_size0.2, random_state42 ) model LinearRegression() model.fit(X_train, y_train) score model.score(X_test, y_test) print(R^2 score:, score)逻辑说明这个脚本完整走了一遍数据加载、切分、训练、评估的全流程load_boston虽然在新版本 sklearn 里已移除但在 Python 3.6.5 sklearn 0.22 的环境里可用。参数说明test_size0.2表示 20% 的数据留作测试集random_state42固定随机种子保证重复运行结果一致。离线环境最怕的是“自己觉得没问题跑起来全是问题”。从那以后我给内网机器搭完环境哪怕再着急也会把这个冒烟测试流程完整走一遍确认解释器、虚拟环境、核心包、真实训练四层全通才算真正交付。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
)
