👇 关注公众号,并选择星标,最新干货每日送达
导读
你是不是也遇到过这种情况?本地写的代码跑的好好的,部署到服务器一运行就报错,查了半天最后发现是requests版本比本地低了0.0.1,某个API参数变了。更气人的是,你明明在requirements.txt里写了requests>=2.25.0,怎么就装上2.24.0了?这背后其实是你对版本约束符号的理解根本不对。
⬆️AI生成
很多人写requirements.txt要么只会写包名,要么全加==锁死版本,其实pip遵循PEP 440规范,有7个明确的版本约束符号,先搞懂版本号规则:主版本号.次版本号.修订号,主版本升代表不兼容API变更,次版本升加新功能,修订号升只修bug。
requests==2.25.1,只能装这个版本,大部分场景属于滥用>=2.25.0,<3.0.0requests!=2.25.0~=2.25.0=≥2.25.0且<2.26.0,~=2.25=≥2.25.0且<3.0.0,既能收bug修复,又不会升到不兼容版本版本约束的核心不是限制,而是用明确的规则减少不确定性。
⬆️AI生成
我见过最离谱的是有人在requirements.txt里写requests==2.25.0,然后另一个依赖包要求requests>=2.26.0,pip直接冲突报错,他还以为是pip坏了。
多个约束取交集,如requests>=2.25.0,<3.0.0,!=2.25.2,代表2.25.0到3.0.0之间,排除2.25.2版本。注意两点:
>=2.26.0,<2.25.0,pip直接报错>=2.26.0rc1package @ git+https://github.com/user/repo.git@commit#egg=package,直接锁死代码版本,开发临时用,上线一定要转正式发布版pywin32>=300; sys_platform == 'win32',只有Windows系统才需要安装>=x.y.z,<x+1.0.0;做业务应用,用lock文件锁死所有依赖的精确版本<x+1.0.0,避免包发大版本API变更直接炸项目,我至少踩过三次这个坑好的requirements.txt不是越严格越好,而是在稳定性和灵活性之间找到平衡点。
我们团队现在用的是Pipenv,虽然有一些小毛病,但虚拟环境和依赖管理集成在一起,对于新人来说更友好,不容易搞混环境。
自动生成不是银弹,不同工具的优缺点差很多,按需选:
⬆️AI生成
pip freeze > requirements.txtpipreqs /path/to/project --encoding=utf8,扫描代码自动提取import的依赖requests>=2.25.0,<3.0.0),运行pip-compile requirements.in自动生成带精确版本的requirements.txtpoetry export不会自动加大版本上限、不会判断跨版本兼容性、平台相关依赖处理不好,生成之后一定要手动检查一遍,删掉不需要的依赖,补全版本上限。
pip install -r requirements.txt-i 国内源地址提速,--no-cache-dir避免缓存问题-U参数升级到约束内最新版本~=2.25和~=2.25.0差很多,前者允许升到2.99.0,后者只能在2.25.x范围内,别写错导致不兼容刚学Python的时候不知道虚拟环境,所有项目都往系统Python里装,最后版本冲突到连pip都用不了,只能重装Python,搞了一下午。
公众号后台回复「加群」加入互助群。

文章仅做学术分享,如有侵权请联系删除,非常感谢!