请问项目中修改第三方包的正确姿势是什么？

直接修改第三方包的源文件，然后通过 Docker 映射文件的方式覆盖掉 优点是项目文件是干净的，缺点是如果第三方包如有升级，出现 bug 可能想不到排查这里。
在项目中导入第三方包，然后手动写好需要修改的类 / 函数，然后进行赋值 优点是第三方包假设有升级，也将影响降低到最低，缺点是可能有我未测出的 bug 。

提 PR 的话我觉得期待得到及时合并不太现实，你们遇到这样的问题都是怎么解决的呢？

第三方

修改

bug

文件

9 条回复 • 2021-11-15 16:46:33 +08:00

wxlwsy

2021-11-14 11:40:33 +08:00

直接改源码吧.上线后几乎不会再有机会更新这个包了

renmu123

2021-11-14 11:44:16 +08:00 via Android

把包复制出来，然后改源码，然后提 pr ，修复之后再删除包。
或者用猴子补丁之类的

xumng123

2021-11-14 12:26:19 +08:00 via iPhone

两种方法：
1. 锁好第三方包版本号，修改代码，以后升级就不升级这个包
2. 继承该包并覆盖对应的部分

ClericPy

2021-11-14 13:19:17 +08:00

目前基本习惯了打补丁, 大部分情况直接覆盖方法或者继承派生一下就够了, 少数情况 (Cython) 就把他们抽象的东西挨个拼出个新的来, 一般流行的包都抽象的挺彻底的

至于未测出的 bug, 改抽象不改具体一般还好, 虽然我现在基本遇到百年不更新的都找到替代品了

ch2

2021-11-14 14:32:24 +08:00

锁定版本号，装完包之后跑个 patch 脚本

ebingtel

2021-11-15 09:16:29 +08:00

在启动的时候，把对应的对象，用自己的代码覆盖掉就行……维护简单

thevita

2021-11-15 10:38:35 +08:00

提 pr+patch+dependent-bot

2i2Re2PLMaDnghL

2021-11-15 14:54:01 +08:00

以最推荐到最不推荐排序

提 PR 直接并入上游
组合+继承，一套 OOP 组合拳
猴子补丁
覆盖 patch ，如果是大更新 patch 会失败，如果上游有比较重要的安全性更新 dependent-bot 会提示
使用你自己的 fork ，采用 pip install git+<giturl> 的形式引入
使用你自己的 fork ，采用 git 子模块引入，锁 commit hash

多线理论上可以同时操作。

Phishion

2021-11-15 16:46:33 +08:00

@2i2Re2PLMaDnghL 牛逼，终结了这个问题