推荐学习书目 Learn Python the Hard Way Python Sites PyPI - Python Package Index http://diveintopython.org/toc/index.html Pocoo 值得关注的项目 PyPy Celery Jinja2 Read the Docs gevent pyenv virtualenv Stackless Python Beautiful Soup 结巴中文分词 Green Unicorn Sentry Shovel Pyflakes pytest Python 编程 pep8 Checker Styles PEP 8 Google Python Style Guide Code Style from The Hitchhiker's Guide
Python 开源项目在进行依赖升级的时候, 是如何规避掉大部分 bug 的?
chaleaochexist 2024-07-22 14:24:51 +08:00 2919 次点击这是一个创建于 451 天前的主题，其中的信息可能已经有所发展或是发生改变。
我司最近进行安全审查, 要求所有的第三方依赖包的版本不能过期. 那就涉及到版本升级问题了, 但是升级就会带来 api 不兼容.
我能想到的就是开源项目也有类似这样的问题.他们是如何解决 api 可能不兼容问题的?
 | 1 Goooooos 2024-07-22 14:26:51 +08:00 via Android 申请人力测试 |
 | 2 AntiEoom 2024-07-22 14:27:05 +08:00 这是哪位领导一拍脑袋想出来的 KPI ，所有第三方都要是最新版，想想最近的 CrowdStrike 不怕死的很难看嘛。 |
 | 3 chaleaochexist OP @AntiEoom 不不不 你这个太极端了 不是非得最新版. |
 | 4 renmu 2024-07-22 14:31:11 +08:00 via Android 人力解决 |
 | 5 huangyezhufeng 2024-07-22 14:32:42 +08:00  1 首先把你的测试覆盖度提到 90%以上，然后核心依赖逐个升级 |
| 6 chaleaochexist OP @huangyezhufeng 开源项目就是依靠单测实现的是吗? |
 | 7 crackidz 2024-07-22 14:34:52 +08:00 有自动化测试吗？即便 API 兼容，也可能实现不兼容 |
 | 8 gotounix 2024-07-22 14:39:17 +08:00 很难做到，如果只是使用第三方库，那还好。如果对第三方库进行了定制，哪怕是继承，都又很大程度上会出问题。 比如这个： https://github.com/mfogel/django-timezone-field/pull/137#issuecomment-2219793300 我是使用 https://github.com/celery/django-celery-beat/ 这个库，然后序列化的时候重写了 timezone_field.TimeZoneField 类。而且，我在 requirements.txt 中使用了 >=。 导致使用这个模板项目，新建项目、安装完依赖后，初始化的时候报错。 这只是一个很简单的例子，很多组件库都有 BREAKING 修改，如果在 CHANGELOG 中有指明还好，没有指明就是一个暗坑。而且，即便指明了，你升级的时候也不会去看每个包的 CHANGELOG 。 |
| 9 huangyezhufeng 2024-07-22 14:39:17 +08:00 @chaleaochexist #6 https://github.com/tiangolo/sqlmodel/issues/654 参考下这个吧，如果升级的依赖有明确的 break change ，每个依赖要单独升。比如从 1.x 升到 2.x ，这里的做法是先升到 1.x 最新版，然后做好测试；然后再慢慢升 2.x 。整个是个挺繁琐的过程... |
 | 10 tangtang369 2024-07-22 14:42:39 +08:00 开源项目第三方依赖包都是固定版本的，升级版本大概率会出现运行不起来的情况 |
 | 11 shakeyo 2024-07-22 15:02:11 +08:00 c++er 成为轮子不是没有理由的 |
 | 12 fcfangcc 2024-07-22 15:20:42 +08:00 无解，纯靠测试。即使 API 兼容，表现也可能不一样。 最近升级了 fastapi 和 pydantic 版本，改了几十个文件。测试了大部分功能后，上线还是发现了好几个不兼容引起的 error |
 | 13 Meteora626 2024-07-22 16:45:14 +08:00 很多都不测，上周遇到的 transformer 和 deepspeed 的问题，搜 GitHub 一堆人提，老版本就没事 |
 | 14 whoosy 2024-07-22 17:14:14 +08:00 快跑 |
 | 15 tomczhen 2024-07-22 17:42:20 +08:00 这个目标达成的成本会很高。 首先，Python 现有的包管理工具我是没找到一个能锁定传递依赖的方法，只能将传递依赖变成主动依赖。 其次，一个环境下一个包只能有一个版本。 另外是否 break change 无法从版本号确定。一旦项目依赖复杂，没有完整的测试覆盖无法发现问题。 而发现问题后，也会遇到必须由上游依赖包来解决的情况。这时想自己解决只能通过维护额外分支解决。 |
 | 16 prosgtsr 2024-07-23 00:06:06 +08:00 开源项目。很有可能就不解决了。用户使用发现了问题再去看要不要修改依赖版本 |
 | 17 Maerd 2024-07-23 11:27:07 +08:00 靠测试用例全覆盖。。。提交 pr 的时候基本上都要求通过测试才能合并 |
 | 18 julyclyde 2024-07-23 12:23:41 +08:00 你们公司这么上进啊？ 要是腾讯肯定是勒令禁止升级以免发生“稳定性”问题，而根本不去研究到底哪个代码的变成引起的问题 |
| 19 julyclyde 2024-07-23 12:25:00 +08:00 |
| 20 chaleaochexist OP |
| 21 chaleaochexist OP @julyclyde >>> 依赖关系是这个版本的一部分，你固定了这个版本，自动就固定了依赖关系 是的, 但是他们自己的版本也要升级啊. 包括依赖关系的升级也是自己版本升级的一部分工作. support pydantic2.0 之类的. 但是我看了一下 对应的开源项目 没太看懂. |
| 22 julyclyde 2024-07-23 13:00:37 +08:00 @chaleaochexist 能定这么正确的 KPI 也挺不容易的 |
Select Language