先给结论Python离线库安装碰壁的人十有八九不是卡在安装动作上而是卡在依赖关系上。很多同学第一次做内网部署时都是辛辛苦苦拷了一个主包的whl文件过去结果pip install一执行报错一大片最后发现是依赖没有一起带过去。这篇文章就把离线装Python库这件事掰开揉碎从有网机器怎么准备依赖包到内网机器怎么安装落地一整套流程给你捋一遍。不管你是第一次做内网部署的新手还是被依赖冲突折磨过的老兵这篇文章都能让你少走几次弯路。1. 先说清楚离线库装不上的锅到底该谁来背1.1 离线安装的真正难点不是拷贝而是依赖链先说个最常见的翻车现场你在有网的机器上执行pip install pandas一次就装好了。到了内网机器你把pandas的whl文件拷过去执行pip install pandas-xxx.whl结果安装阶段就报pandas is not a supported wheel on this platform或者安装成功但一import就报ImportError: Missing required dependencies。为啥因为pip在安装whl时会根据这个包metadata里声明的Requires-Dist字段去检查依赖。pandas依赖numpy、pytz、python-dateutil这一串包这些依赖没装或者版本对不上光有一个主包根本跑不起来。所以离线安装的本质是把包的依赖树完整搬运过去而不是把一个包搬运过去。我习惯把这条链叫依赖链。你在有网机器上执行pip installpip会递归解析依赖到了离线环境没有网络去PyPI查询依赖关系每一步都得你提前想清楚。这也是为什么很多人拷贝单个whl会反复失败——不是包不对而是链断了。更麻烦的是pip在离线安装时处于盲装状态只能根据当前环境已有的包判断满不满足Requires-Dist缺什么它不会主动去查询而是直接报找不到版本。你只能手动把依赖一个个补齐。1.2 什么场景最需要离线库安装我总结下来离线库需求基本集中在三类场景你可以对照一下自己属于哪一类。内网生产环境服务器不允许出外网或者安全基线要求所有软件包必须经过审核才能进入生产网人工从有网机器拷包是常态。我自己在给一些信贷类项目做部署时就经常遇到只能带进去一个U盘的情况。开发机与部署机网络隔离不少公司开发环境与外网物理隔离代码可以在开发网写完依赖包只能通过介质引导进去。这种情况下光靠一两个whl根本不够用。外网出口不稳定有些朋友不是完全没网而是公司网络出口慢得令人发指pip install动不动就超时与其反复重试不如先在有网环境把包完整下载好拿回本地离线安装。这些场景里最容易被低估的是全量依赖这个工作量。你以为只装一个scikit-learn结果发现它背后还挂着一串numpy、scipy、joblib、threadpoolctl。所以离线安装的方案一定不能只围绕安装命令设计必须围绕依赖解析和打包来设计。理解了这一点后面所有操作你才会觉得顺理成章。2. 方案选型三条主流的离线安装路径2.1 方案A使用pip download全量预下载最推荐这是我个人最推荐的做法核心思路是在有网机器上用pip download命令让pip按照当前环境的解释器版本、平台和依赖关系把所需包以及所有子依赖全部下载到指定目录不执行安装。之后把整个目录拷贝到离线机器再用pip install --no-index --find-links指向这个目录完成安装。这个方案最大的好处是依赖由pip自动解析不用你手动去查每个包依赖谁。而且下载阶段就可以指定目标平台的架构和Python版本提前过滤掉不适配的包。只要你在有网机器上把命令执行对了到了离线环境基本不会出幺蛾子。唯一要付出的就是先在有网环境做一次下载操作以及保证有网机器和目标机器的Python大版本一致。对于大多数场景来说这都是成本最低、可控性最高的方案。2.2 方案B直接拷贝whl文件有些人图省事直接从网上下载几个whl文件拷过去。这个方案只适合两种情况要么你装的包没有任何第三方依赖要么你对依赖关系熟得不能再熟。举例子你要给内网机器装一个纯标准库写的小工具包那拷贝一个whl确实够用。但你要是装requests、Flask这类有依赖的包只拷主包的whl几乎必翻车。requests背后挂着urllib3、certifi、idna、charset_normalizer缺一个都会在运行时炸出来。还有一点whl文件的平台标签非常严格。你在Windows上下的whl肯定没法在Linux上用哪怕都是Linuxx86_64和aarch64也不通用。所以直接拷贝whl只适合临时补一个小包不适合做整套环境迁移。2.3 方案C搭建内部PyPI镜像源如果是一个团队长期有离线安装需求比如每次发版都要在内网装大量包那可以考虑自建私有的PyPI源。比较常见的做法是部署devpi、Nexus或者用bandersnatch做PyPI全量镜像。这个方案的优点是以后内网机器可以直接pip install跟外网体验一致不需要每次都手动拷贝目录缺点是基础设施成本不低需要维护存储和同步策略个人单机部署完全没必要上。我也见过不少团队用最朴素的方式搭内部源在内网一台机器上跑python -m http.server把wheel目录暴露成HTTP服务pip install --index-url指向它。这种方式能用但没有依赖索引结构pip解析时容易出问题不如直接用devpi这类正经工具。整体来说方案C适合有长期运维投入的团队单次离线部署用方案A就够了。方案准备成本依赖处理适合规模门槛pip download低自动解析单次部署、小批量低拷贝whl极低手动处理单包安装低但风险高私有PyPI源高自动解析长期多项目团队中高从投入产出比来看普通项目直接用方案A别跟我一样一开始图省事拿方案B硬顶结果在依赖上反复折腾到怀疑人生。3. 实操一在有网环境准备好干粮3.1 先锁定依赖清单requirements.txt的正确写法离线安装的第一步不是急着下载而是先把requirements.txt整明白。很多人在这一步就没做对。如果你要迁移整个Python环境直接在原来的有网机器上执行pip freeze requirements.txt。这个命令会把当前环境里所有已安装的包连同精确版本号全部列出来适合环境搬家的场景。缺点是大而全连一些垃圾测试包也会带进去交给内网机器装的时候容易装出一堆没用的东西。如果你只是部署一个具体项目我建议用pipreqs做项目级依赖扫描。你要先在项目目录下装一个pipreqspip install pipreqs pipreqs ./project_dir --force它会去扫描代码里的import语句只生成项目真正用到的依赖清单。这样做出来的requirements.txt干净且有的放矢离线安装时包数量会少很多。要注意的是pipreqs不会识别动态导入的模块和运行时才import的库扫完之后最好人工过一遍把那些写在配置里、按插件机制加载的包补进去。requirements.txt里版本号的写法也有讲究。我推荐全部锁定精确版本比如numpy1.24.3。不要用或者~因为离线安装没法临时解析最新版本一旦版本漂移前面准备的一堆包可能因为这一个版本变化互相冲突。3.2 pip download核心参数详解锁定依赖清单以后就可以在有网机器上执行下载了。最基础的命令是pip download -r requirements.txt -d ./offline_pkgs这条命令会把requirements.txt里所有包以及它们的依赖全部下载到当前目录下的offline_pkgs文件夹里。下载下来的文件一般是whl格式少数没有提供wheel的包会以tar.gz源码包形式出现。但如果你要按目标环境交叉下载基础命令就不够用了需要加上平台和解释器相关参数。比如目标内网机是Linux x86_64、Python 3.8那我会这样写pip download -r requirements.txt -d ./offline_pkgs \ --platform manylinux2014_x86_64 \ --python-version 3.8 \ --implementation cp \ --abi cp38 \ --only-binary:all:这里每个参数都有它存在的道理。--platform指定目标平台标签manylinux2014_x86_64覆盖了大多数x86_64的Linux发行版--python-version指定目标Python版本--implementation表示用CPython解释器--abi指定ABI接口cp38表示Python 3.8的C扩展兼容层。最关键的其实是--only-binary:all:它的意思是全部只下载wheel二进制包不碰source包。因为源码包到了离线环境往往还需要编译可能在缺gcc的机器上直接卡死。加上这个参数后如果某个包只有源码没有wheel命令会主动报错提示你好提前想办法而不是等到离线机器上才发现装不了。如果你不确定目标机器到底需要什么平台标签最简单的方式是在目标机器上执行python -c import pip._internal; print(pip._internal.models.target_python.get_target_python(None, [], None, [], None, None, False).get_tags() if hasattr(pip._internal.models, target_python) else not easy)或者更粗暴一点直接看已装wheel包的文件名里的平台标签。说实话最靠谱的方法是在一台和目标系统一致的有网机器上执行pip download不带任何平台参数这样下载的就是本机平台兼容的wheel不容易出错。3.3 平台与Python版本不匹配怎么处理交叉下载时最常见的花式报错就是is not a supported wheel on this platform。出现这个问题的根本原因是你下载的whl文件标签和目标环境的平台、Python版本不匹配。比如你在Windows上下载了win_amd64的包拿到Linux服务器上当然装不上。处理思路有几条。第一确认目标机器的操作系统位宽执行uname -m看是x86_64还是aarch64。第二确认目标机器的Python版本必须是3.8就下cp38的包不能拿3.10的包硬塞。第三注意glibc版本。CentOS 6、CentOS 7这种老系统glibc比较旧很多新编译的manylinux2014 wheel可能不兼容这时候你只能找旧版本的wheel或者干脆用源码编译。另外要注意Python 3.8和3.8.x的ABI通常是一致的只要主版本号相同cp38标签的wheel基本通用。真正的分水岭是大版本切换比如3.8换3.9C扩展模块几乎都要重新编译。所以准备离线库时一个铁律就是有网机器和目标机器的Python版本最好完全一致否则你下载阶段做得再精细到了内网照样翻车。4. 实操二离线环境安装全流程4.1 把包安全地传输过去下载完成后别急着直接拷。先把offline_pkgs目录压缩一下然后做一个文件校验。我一般会生成一个SHA256校验文件因为离线传输过程中U盘损坏、网络中断这种事不是没遇到过cd ./offline_pkgs sha256sum * SHA256SUMS.txt cd .. tar czf offline_pkgs.tar.gz offline_pkgs把压缩包带到内网之后先解压到固定目录。我通常习惯把所有离线包放到/opt/offline_pkgs这个路径固定下来也有好处以后再来补装包直接把新包丢进去就行。解压完顺手执行sha256sum -c SHA256SUMS.txt核对每个包的完整性。这一步虽然多花十几秒但能避免安装到一半突然报package file is corrupt这种恶心问题。4.2 使用--no-index和--find-links进行本地安装到了离线机器上安装命令不复杂核心是下面这条pip install \ --no-index \ --find-links/opt/offline_pkgs \ -r requirements.txt--no-index的意思是明确告诉pip不许去访问PyPI哪怕它自己找到源也不行。--find-links的意思是告诉pip去哪个本地目录找包。这两个参数通常是成对出现的缺失一个都会出问题。很多人离线安装时卡在一种诡异现象明明包就在本地目录里命令执行后却一直卡着不动最后报超时。出现这个情况往往就是因为漏了--no-index。pip默认还是会去PyPI建立连接离线环境下连接超时要等半天才放弃看起来就像卡死了一样。加上--no-index后pip直接跳过所有远端检查干净利落。如果只安装单个包而不是整个requirements也可以这么写pip install --no-index --find-links/opt/offline_pkgs scikit-learnpip会先查看本地目录有没有满足条件的包有了才装没有再报No matching distribution found。所以离线安装遇到这种报错第一反应应该是这个包的依赖或者它本身没有出现在--find-links目录里而不是怪命令写错了。4.3 源码包tar.gz的安装特例如果你在下载阶段没有加--only-binary:all:或者某个包实在没有wheel提供那你会在offline_pkgs目录里看到一堆.tar.gz源码包。这些包在离线机器上安装时pip会尝试解压然后执行setup.py、setup.cfg定义的构建流程这时候就需要目标机器具备编译工具链。我当时踩过的坑是内网机器是精简安装的CentOS连gcc都没有装一个纯C扩展包直接报error: command gcc failed with exit status 1。从那以后我就养成了习惯离线装项目之前先把编译依赖准备好。Debian/Ubuntu系统执行apt install build-essential python3-devCentOS/RHEL系统执行yum install gcc gcc-c python3-devel。这些工具建议在初始环境初始化时一次性装好不要等到报错了再去想办法递二进制包进来那就太被动了。如果这个包可以在有网环境找到历史版本的wheel强烈建议优先下载wheel版本哪怕是旧一点的版本。很多包在PyPI上保留了几个版本的wheel文件用--platform、--python-version和--only-binary:all:组合去抓旧版本往往能避开源码编译的问题。实在找不到wheel再考虑源码编译。5. 依赖管理的坑被版本冲突支配的恐惧5.1 环境里已有旧版本包怎么办很多内网机器并不是一个干净环境Python里可能已经装了一些系统自带的旧包比如python-daemon、setuptools的老版本。这时候你直接用requirements.txt安装新包与已装旧版本可能产生冲突。我建议在离线安装前先做一次环境体检pip list pip checkpip list看已经装了哪些包pip check检查当前环境的依赖是不是健康。如果检查结果有冲突要么升级这些旧包到requirements里要求的版本要么干脆在工作目录里新建一个虚拟环境别在系统Python里折腾。新建虚拟环境这个做法我认为是最稳的尤其是在离线部署场景python3 -m venv /opt/myproject_venv source /opt/myproject_venv/bin/activate之后所有离线安装操作都在虚拟环境里做系统里原有的依赖就算乱成一锅粥也影响不到你。这其实就是用隔离来对抗版本冲突比手动去调依赖关系省心得多。而且虚拟环境目录随时可以删掉重建这次装失败了大不了把目录删了再来一次完全不影响系统Python。5.2 用pipdeptree和pip check排查依赖链离线环境最怕什么最怕装完之后一运行就报ImportError但报错的包似乎又已经装过了。这种谜之问题通常有两种来源一是包确实没装进当前正在使用的Python解释器二是装进去了但版本和另一个依赖它运行的包不兼容。排查这种问题我推荐两个工具组合使用。第一个是pipdeptree它能把当前环境里的依赖关系树完整画出来哪个包依赖哪个包一目了然。pipdeptree本身也需要在离线目录里准备建议在有网机器上下载的时候就把pipdeptree也一并下载好放到offline_pkgs里。第二个是pip check它可以自动检测当前环境中是否存在依赖缺失或版本冲突。实操思路很简单离线装完一批包后立刻执行pip check。如果有红字报错再执行pipdeptree -p 有问题包名看它依赖了什么版本然后回到离线包的目录里找有没有对应版本的文件。这种排查方式比靠着报错信息瞎猜快太多我几乎每次离线部署都会用这一套组合拳。5.3 有网机器和离线机器的环境一致性所有离线安装问题的根源都指向同一个核心环境不一致。你在有网机器的Python 3.9上下载好了全套依赖结果目标内网机器是Python 3.8那大部分带C扩展的库都会直接报平台不支持。你在有网机器是Windows目标机器是Linux那更是一场灾难。所以我在这里给出一个硬性建议准备离线库的有网机器尽量和目标内网机器使用相同的操作系统、相同的系统位数、相同的Python版本。不要抱着侥幸心理觉得都是Python应该差不多差一个版本号很多二进制包就是装不上。如果实在找不到完全一致的机器至少要做两件事。第一确认目标机器的Python主版本下载时用--python-version参数锁定第二确认目标机器的架构下载时用--platform参数锁定。只要这两项参数设得对就算系统模板有些差异绝大多数情况下也能安装成功。6. 常见问题速查表与独家避坑经验6.1 高频报错对照表我在离线安装这条路上踩过的坑不少把高频报错整理成了一张速查表每一条都有对应的解决方案你可以直接对着抄报错/现象根因解决办法is not a supported wheel on this platform包的平台标签与当前系统不匹配核对目标机器架构、Python版本、glibc版本下载对应platform的包Could not find a version that satisfies the requirement本地目录里根本没有满足要求的包检查offline_pkgs目录是否完整确认有没有漏掉依赖No matching distribution found for ...这个包或其依赖没有出现在本地回到有网机器重新执行pip download补齐缺失的包error: command gcc failed with exit status 1tar.gz源码包需要编译但缺少编译链安装build-essential/python3-devRetrying... connection error离线环境执行安装时没加--no-index安装命令必须带上--no-index --find-linksImportError: Missing required dependencies主包装好了但依赖没装用pip check检查依赖从offline_pkgs补齐依赖包WARNING: Skipping package as it is not downloadedpip认为文件不完整或类型不对检查文件是否下载完整重新拉取或更换源这张表我建议直接收藏遇到问题先对表查一遍别着急去百度搜各种玄学方案。6.2 我自己一路踩坑后总结的心得写了这么多最后分享几个我在实际工作中养成的习惯它们真的帮我省了很多时间。第一无论项目大小准备工作都按三件套来做requirements.txt、offline_pkgs目录、SHA256校验文件。这三样齐了离线环境装不上一定是环境差异问题而不是流程问题。第二下载完成后务必在有网机器上用一个全新的虚拟环境按同样命令先试装一遍。我在有网机器上新建一个venv然后执行和离线机器一样的pip install --no-index --find-links./offline_pkgs -r requirements.txt如果这个流程能通打包带给内网机器基本稳了。这一步相当于在运输前做一次空运演练把依赖缺漏、平台不匹配这类问题提前暴露出来。第三tar.gz源码包能避则避。离线环境加上编译工具链的安装复杂度直接翻倍。如果非装不可一定要先在目标机器上把编译环境全部就绪并且最好选一个有经验的同事在旁边盯着不然编译日志几百行报错新手根本看不出来哪里出了问题。第四养成用虚拟环境隔离的习惯。每次离线部署我都建议在目标机器上新建venv而不是直接装在系统Python里。别怕那点磁盘开销虚拟环境带来的干净隔离能让所有依赖问题都变得可预测、可重现、可回滚。最后再分享一个实际操作技巧在offline_pkgs目录里放一个README.txt把下载时间、源码机器信息、目标机器信息、Python版本都记录下来。别小看这几行字隔三个月再回来补包时你会感谢自己当时记下的这些细节。反正我现在每次去内网装环境都带着一个固定的离线包目录遇到缺什么直接装什么基本不用再折腾。希望这篇文章能帮你少走一次弯路。
先给结论Python离线库安装碰壁的人十有八九不是卡在安装动作上而是卡在依赖关系上。很多同学第一次做内网部署时都是辛辛苦苦拷了一个主包的whl文件过去结果pip install一执行报错一大片最后发现是依赖没有一起带过去。这篇文章就把离线装Python库这件事掰开揉碎从有网机器怎么准备依赖包到内网机器怎么安装落地一整套流程给你捋一遍。不管你是第一次做内网部署的新手还是被依赖冲突折磨过的老兵这篇文章都能让你少走几次弯路。1. 先说清楚离线库装不上的锅到底该谁来背1.1 离线安装的真正难点不是拷贝而是依赖链先说个最常见的翻车现场你在有网的机器上执行pip install pandas一次就装好了。到了内网机器你把pandas的whl文件拷过去执行pip install pandas-xxx.whl结果安装阶段就报pandas is not a supported wheel on this platform或者安装成功但一import就报ImportError: Missing required dependencies。为啥因为pip在安装whl时会根据这个包metadata里声明的Requires-Dist字段去检查依赖。pandas依赖numpy、pytz、python-dateutil这一串包这些依赖没装或者版本对不上光有一个主包根本跑不起来。所以离线安装的本质是把包的依赖树完整搬运过去而不是把一个包搬运过去。我习惯把这条链叫依赖链。你在有网机器上执行pip installpip会递归解析依赖到了离线环境没有网络去PyPI查询依赖关系每一步都得你提前想清楚。这也是为什么很多人拷贝单个whl会反复失败——不是包不对而是链断了。更麻烦的是pip在离线安装时处于盲装状态只能根据当前环境已有的包判断满不满足Requires-Dist缺什么它不会主动去查询而是直接报找不到版本。你只能手动把依赖一个个补齐。1.2 什么场景最需要离线库安装我总结下来离线库需求基本集中在三类场景你可以对照一下自己属于哪一类。内网生产环境服务器不允许出外网或者安全基线要求所有软件包必须经过审核才能进入生产网人工从有网机器拷包是常态。我自己在给一些信贷类项目做部署时就经常遇到只能带进去一个U盘的情况。开发机与部署机网络隔离不少公司开发环境与外网物理隔离代码可以在开发网写完依赖包只能通过介质引导进去。这种情况下光靠一两个whl根本不够用。外网出口不稳定有些朋友不是完全没网而是公司网络出口慢得令人发指pip install动不动就超时与其反复重试不如先在有网环境把包完整下载好拿回本地离线安装。这些场景里最容易被低估的是全量依赖这个工作量。你以为只装一个scikit-learn结果发现它背后还挂着一串numpy、scipy、joblib、threadpoolctl。所以离线安装的方案一定不能只围绕安装命令设计必须围绕依赖解析和打包来设计。理解了这一点后面所有操作你才会觉得顺理成章。2. 方案选型三条主流的离线安装路径2.1 方案A使用pip download全量预下载最推荐这是我个人最推荐的做法核心思路是在有网机器上用pip download命令让pip按照当前环境的解释器版本、平台和依赖关系把所需包以及所有子依赖全部下载到指定目录不执行安装。之后把整个目录拷贝到离线机器再用pip install --no-index --find-links指向这个目录完成安装。这个方案最大的好处是依赖由pip自动解析不用你手动去查每个包依赖谁。而且下载阶段就可以指定目标平台的架构和Python版本提前过滤掉不适配的包。只要你在有网机器上把命令执行对了到了离线环境基本不会出幺蛾子。唯一要付出的就是先在有网环境做一次下载操作以及保证有网机器和目标机器的Python大版本一致。对于大多数场景来说这都是成本最低、可控性最高的方案。2.2 方案B直接拷贝whl文件有些人图省事直接从网上下载几个whl文件拷过去。这个方案只适合两种情况要么你装的包没有任何第三方依赖要么你对依赖关系熟得不能再熟。举例子你要给内网机器装一个纯标准库写的小工具包那拷贝一个whl确实够用。但你要是装requests、Flask这类有依赖的包只拷主包的whl几乎必翻车。requests背后挂着urllib3、certifi、idna、charset_normalizer缺一个都会在运行时炸出来。还有一点whl文件的平台标签非常严格。你在Windows上下的whl肯定没法在Linux上用哪怕都是Linuxx86_64和aarch64也不通用。所以直接拷贝whl只适合临时补一个小包不适合做整套环境迁移。2.3 方案C搭建内部PyPI镜像源如果是一个团队长期有离线安装需求比如每次发版都要在内网装大量包那可以考虑自建私有的PyPI源。比较常见的做法是部署devpi、Nexus或者用bandersnatch做PyPI全量镜像。这个方案的优点是以后内网机器可以直接pip install跟外网体验一致不需要每次都手动拷贝目录缺点是基础设施成本不低需要维护存储和同步策略个人单机部署完全没必要上。我也见过不少团队用最朴素的方式搭内部源在内网一台机器上跑python -m http.server把wheel目录暴露成HTTP服务pip install --index-url指向它。这种方式能用但没有依赖索引结构pip解析时容易出问题不如直接用devpi这类正经工具。整体来说方案C适合有长期运维投入的团队单次离线部署用方案A就够了。方案准备成本依赖处理适合规模门槛pip download低自动解析单次部署、小批量低拷贝whl极低手动处理单包安装低但风险高私有PyPI源高自动解析长期多项目团队中高从投入产出比来看普通项目直接用方案A别跟我一样一开始图省事拿方案B硬顶结果在依赖上反复折腾到怀疑人生。3. 实操一在有网环境准备好干粮3.1 先锁定依赖清单requirements.txt的正确写法离线安装的第一步不是急着下载而是先把requirements.txt整明白。很多人在这一步就没做对。如果你要迁移整个Python环境直接在原来的有网机器上执行pip freeze requirements.txt。这个命令会把当前环境里所有已安装的包连同精确版本号全部列出来适合环境搬家的场景。缺点是大而全连一些垃圾测试包也会带进去交给内网机器装的时候容易装出一堆没用的东西。如果你只是部署一个具体项目我建议用pipreqs做项目级依赖扫描。你要先在项目目录下装一个pipreqspip install pipreqs pipreqs ./project_dir --force它会去扫描代码里的import语句只生成项目真正用到的依赖清单。这样做出来的requirements.txt干净且有的放矢离线安装时包数量会少很多。要注意的是pipreqs不会识别动态导入的模块和运行时才import的库扫完之后最好人工过一遍把那些写在配置里、按插件机制加载的包补进去。requirements.txt里版本号的写法也有讲究。我推荐全部锁定精确版本比如numpy1.24.3。不要用或者~因为离线安装没法临时解析最新版本一旦版本漂移前面准备的一堆包可能因为这一个版本变化互相冲突。3.2 pip download核心参数详解锁定依赖清单以后就可以在有网机器上执行下载了。最基础的命令是pip download -r requirements.txt -d ./offline_pkgs这条命令会把requirements.txt里所有包以及它们的依赖全部下载到当前目录下的offline_pkgs文件夹里。下载下来的文件一般是whl格式少数没有提供wheel的包会以tar.gz源码包形式出现。但如果你要按目标环境交叉下载基础命令就不够用了需要加上平台和解释器相关参数。比如目标内网机是Linux x86_64、Python 3.8那我会这样写pip download -r requirements.txt -d ./offline_pkgs \ --platform manylinux2014_x86_64 \ --python-version 3.8 \ --implementation cp \ --abi cp38 \ --only-binary:all:这里每个参数都有它存在的道理。--platform指定目标平台标签manylinux2014_x86_64覆盖了大多数x86_64的Linux发行版--python-version指定目标Python版本--implementation表示用CPython解释器--abi指定ABI接口cp38表示Python 3.8的C扩展兼容层。最关键的其实是--only-binary:all:它的意思是全部只下载wheel二进制包不碰source包。因为源码包到了离线环境往往还需要编译可能在缺gcc的机器上直接卡死。加上这个参数后如果某个包只有源码没有wheel命令会主动报错提示你好提前想办法而不是等到离线机器上才发现装不了。如果你不确定目标机器到底需要什么平台标签最简单的方式是在目标机器上执行python -c import pip._internal; print(pip._internal.models.target_python.get_target_python(None, [], None, [], None, None, False).get_tags() if hasattr(pip._internal.models, target_python) else not easy)或者更粗暴一点直接看已装wheel包的文件名里的平台标签。说实话最靠谱的方法是在一台和目标系统一致的有网机器上执行pip download不带任何平台参数这样下载的就是本机平台兼容的wheel不容易出错。3.3 平台与Python版本不匹配怎么处理交叉下载时最常见的花式报错就是is not a supported wheel on this platform。出现这个问题的根本原因是你下载的whl文件标签和目标环境的平台、Python版本不匹配。比如你在Windows上下载了win_amd64的包拿到Linux服务器上当然装不上。处理思路有几条。第一确认目标机器的操作系统位宽执行uname -m看是x86_64还是aarch64。第二确认目标机器的Python版本必须是3.8就下cp38的包不能拿3.10的包硬塞。第三注意glibc版本。CentOS 6、CentOS 7这种老系统glibc比较旧很多新编译的manylinux2014 wheel可能不兼容这时候你只能找旧版本的wheel或者干脆用源码编译。另外要注意Python 3.8和3.8.x的ABI通常是一致的只要主版本号相同cp38标签的wheel基本通用。真正的分水岭是大版本切换比如3.8换3.9C扩展模块几乎都要重新编译。所以准备离线库时一个铁律就是有网机器和目标机器的Python版本最好完全一致否则你下载阶段做得再精细到了内网照样翻车。4. 实操二离线环境安装全流程4.1 把包安全地传输过去下载完成后别急着直接拷。先把offline_pkgs目录压缩一下然后做一个文件校验。我一般会生成一个SHA256校验文件因为离线传输过程中U盘损坏、网络中断这种事不是没遇到过cd ./offline_pkgs sha256sum * SHA256SUMS.txt cd .. tar czf offline_pkgs.tar.gz offline_pkgs把压缩包带到内网之后先解压到固定目录。我通常习惯把所有离线包放到/opt/offline_pkgs这个路径固定下来也有好处以后再来补装包直接把新包丢进去就行。解压完顺手执行sha256sum -c SHA256SUMS.txt核对每个包的完整性。这一步虽然多花十几秒但能避免安装到一半突然报package file is corrupt这种恶心问题。4.2 使用--no-index和--find-links进行本地安装到了离线机器上安装命令不复杂核心是下面这条pip install \ --no-index \ --find-links/opt/offline_pkgs \ -r requirements.txt--no-index的意思是明确告诉pip不许去访问PyPI哪怕它自己找到源也不行。--find-links的意思是告诉pip去哪个本地目录找包。这两个参数通常是成对出现的缺失一个都会出问题。很多人离线安装时卡在一种诡异现象明明包就在本地目录里命令执行后却一直卡着不动最后报超时。出现这个情况往往就是因为漏了--no-index。pip默认还是会去PyPI建立连接离线环境下连接超时要等半天才放弃看起来就像卡死了一样。加上--no-index后pip直接跳过所有远端检查干净利落。如果只安装单个包而不是整个requirements也可以这么写pip install --no-index --find-links/opt/offline_pkgs scikit-learnpip会先查看本地目录有没有满足条件的包有了才装没有再报No matching distribution found。所以离线安装遇到这种报错第一反应应该是这个包的依赖或者它本身没有出现在--find-links目录里而不是怪命令写错了。4.3 源码包tar.gz的安装特例如果你在下载阶段没有加--only-binary:all:或者某个包实在没有wheel提供那你会在offline_pkgs目录里看到一堆.tar.gz源码包。这些包在离线机器上安装时pip会尝试解压然后执行setup.py、setup.cfg定义的构建流程这时候就需要目标机器具备编译工具链。我当时踩过的坑是内网机器是精简安装的CentOS连gcc都没有装一个纯C扩展包直接报error: command gcc failed with exit status 1。从那以后我就养成了习惯离线装项目之前先把编译依赖准备好。Debian/Ubuntu系统执行apt install build-essential python3-devCentOS/RHEL系统执行yum install gcc gcc-c python3-devel。这些工具建议在初始环境初始化时一次性装好不要等到报错了再去想办法递二进制包进来那就太被动了。如果这个包可以在有网环境找到历史版本的wheel强烈建议优先下载wheel版本哪怕是旧一点的版本。很多包在PyPI上保留了几个版本的wheel文件用--platform、--python-version和--only-binary:all:组合去抓旧版本往往能避开源码编译的问题。实在找不到wheel再考虑源码编译。5. 依赖管理的坑被版本冲突支配的恐惧5.1 环境里已有旧版本包怎么办很多内网机器并不是一个干净环境Python里可能已经装了一些系统自带的旧包比如python-daemon、setuptools的老版本。这时候你直接用requirements.txt安装新包与已装旧版本可能产生冲突。我建议在离线安装前先做一次环境体检pip list pip checkpip list看已经装了哪些包pip check检查当前环境的依赖是不是健康。如果检查结果有冲突要么升级这些旧包到requirements里要求的版本要么干脆在工作目录里新建一个虚拟环境别在系统Python里折腾。新建虚拟环境这个做法我认为是最稳的尤其是在离线部署场景python3 -m venv /opt/myproject_venv source /opt/myproject_venv/bin/activate之后所有离线安装操作都在虚拟环境里做系统里原有的依赖就算乱成一锅粥也影响不到你。这其实就是用隔离来对抗版本冲突比手动去调依赖关系省心得多。而且虚拟环境目录随时可以删掉重建这次装失败了大不了把目录删了再来一次完全不影响系统Python。5.2 用pipdeptree和pip check排查依赖链离线环境最怕什么最怕装完之后一运行就报ImportError但报错的包似乎又已经装过了。这种谜之问题通常有两种来源一是包确实没装进当前正在使用的Python解释器二是装进去了但版本和另一个依赖它运行的包不兼容。排查这种问题我推荐两个工具组合使用。第一个是pipdeptree它能把当前环境里的依赖关系树完整画出来哪个包依赖哪个包一目了然。pipdeptree本身也需要在离线目录里准备建议在有网机器上下载的时候就把pipdeptree也一并下载好放到offline_pkgs里。第二个是pip check它可以自动检测当前环境中是否存在依赖缺失或版本冲突。实操思路很简单离线装完一批包后立刻执行pip check。如果有红字报错再执行pipdeptree -p 有问题包名看它依赖了什么版本然后回到离线包的目录里找有没有对应版本的文件。这种排查方式比靠着报错信息瞎猜快太多我几乎每次离线部署都会用这一套组合拳。5.3 有网机器和离线机器的环境一致性所有离线安装问题的根源都指向同一个核心环境不一致。你在有网机器的Python 3.9上下载好了全套依赖结果目标内网机器是Python 3.8那大部分带C扩展的库都会直接报平台不支持。你在有网机器是Windows目标机器是Linux那更是一场灾难。所以我在这里给出一个硬性建议准备离线库的有网机器尽量和目标内网机器使用相同的操作系统、相同的系统位数、相同的Python版本。不要抱着侥幸心理觉得都是Python应该差不多差一个版本号很多二进制包就是装不上。如果实在找不到完全一致的机器至少要做两件事。第一确认目标机器的Python主版本下载时用--python-version参数锁定第二确认目标机器的架构下载时用--platform参数锁定。只要这两项参数设得对就算系统模板有些差异绝大多数情况下也能安装成功。6. 常见问题速查表与独家避坑经验6.1 高频报错对照表我在离线安装这条路上踩过的坑不少把高频报错整理成了一张速查表每一条都有对应的解决方案你可以直接对着抄报错/现象根因解决办法is not a supported wheel on this platform包的平台标签与当前系统不匹配核对目标机器架构、Python版本、glibc版本下载对应platform的包Could not find a version that satisfies the requirement本地目录里根本没有满足要求的包检查offline_pkgs目录是否完整确认有没有漏掉依赖No matching distribution found for ...这个包或其依赖没有出现在本地回到有网机器重新执行pip download补齐缺失的包error: command gcc failed with exit status 1tar.gz源码包需要编译但缺少编译链安装build-essential/python3-devRetrying... connection error离线环境执行安装时没加--no-index安装命令必须带上--no-index --find-linksImportError: Missing required dependencies主包装好了但依赖没装用pip check检查依赖从offline_pkgs补齐依赖包WARNING: Skipping package as it is not downloadedpip认为文件不完整或类型不对检查文件是否下载完整重新拉取或更换源这张表我建议直接收藏遇到问题先对表查一遍别着急去百度搜各种玄学方案。6.2 我自己一路踩坑后总结的心得写了这么多最后分享几个我在实际工作中养成的习惯它们真的帮我省了很多时间。第一无论项目大小准备工作都按三件套来做requirements.txt、offline_pkgs目录、SHA256校验文件。这三样齐了离线环境装不上一定是环境差异问题而不是流程问题。第二下载完成后务必在有网机器上用一个全新的虚拟环境按同样命令先试装一遍。我在有网机器上新建一个venv然后执行和离线机器一样的pip install --no-index --find-links./offline_pkgs -r requirements.txt如果这个流程能通打包带给内网机器基本稳了。这一步相当于在运输前做一次空运演练把依赖缺漏、平台不匹配这类问题提前暴露出来。第三tar.gz源码包能避则避。离线环境加上编译工具链的安装复杂度直接翻倍。如果非装不可一定要先在目标机器上把编译环境全部就绪并且最好选一个有经验的同事在旁边盯着不然编译日志几百行报错新手根本看不出来哪里出了问题。第四养成用虚拟环境隔离的习惯。每次离线部署我都建议在目标机器上新建venv而不是直接装在系统Python里。别怕那点磁盘开销虚拟环境带来的干净隔离能让所有依赖问题都变得可预测、可重现、可回滚。最后再分享一个实际操作技巧在offline_pkgs目录里放一个README.txt把下载时间、源码机器信息、目标机器信息、Python版本都记录下来。别小看这几行字隔三个月再回来补包时你会感谢自己当时记下的这些细节。反正我现在每次去内网装环境都带着一个固定的离线包目录遇到缺什么直接装什么基本不用再折腾。希望这篇文章能帮你少走一次弯路。
