Python 能不能像 node 一样管理包

2022-08-03 10:44:05 +08:00
 yuhangch

拉下来仓库,装上依赖能跑,删除项目依赖也就没了

conda 这种需要手动创建虚拟环境,没办法跟某个项目同步创建、删除

8625 次点击
所在节点    Python
56 条回复
wxf666
2022-08-03 13:29:23 +08:00
@yuhangch ,最基础的 virtualenv 都能支持项目级依赖啊,Pycharm 默认的虚拟环境就是这货
cherryas
2022-08-03 13:33:12 +08:00
有没有可能 python 不 import 就等于 node 不装依赖
dcoder
2022-08-03 14:00:44 +08:00
@yuhangch
用 poetry 啊
wdhwg001
2022-08-03 14:16:49 +08:00
poetry 是一个基于 venv 的依赖安装工具。
pdm 是一个可以基于 venv 也可以在文件夹内安装依赖的工具。

poetry 诞生于各种相关的 PEP 出现前,所以它给 pyproject.toml 里写的内容是私有格式的,要到 2.0 版本才能支持 PEP 621 格式的依赖。

pdm 诞生于这些 PEP 出现后,所以它天生就支持这些新的 PEP 。
wdhwg001
2022-08-03 14:23:39 +08:00
补充:pdm 提供了 poetry 格式的兼容转换,而 poetry 则没有提供。

另外 pdm 的开发者是国人,这一点或许可以影响一小部分判断。但 pdm 的质量实际上比早期 poetry 的质量强多了,用过早期 poetry 的都知道它有多少莫名其妙的小 bug 。
qbug
2022-08-03 14:35:52 +08:00
@1543544726zy container 大法好!不过 docker 貌似已经不太行了,不但被巨头打压,自己的也没做得太好,podman 确实香。
shyling
2022-08-03 14:38:59 +08:00
@wxf666 依靠环境变量啊
yedanten
2022-08-03 14:56:57 +08:00
node 的依赖管理就是噩梦,竟然还想复刻
supercaizehua
2022-08-03 14:57:26 +08:00
据说 pdm 挺好用的
wxf666
2022-08-03 15:09:01 +08:00
@shyling 依靠什么环境变量?即使不 source <venv>/bin/activate ,直接运行 .py 文件也没问题啊
thinkershare
2022-08-03 15:20:48 +08:00
一些包这么搞可能没问题, 但很多 Python 包, 你换一个环境, 根本没法运行, 即便你拷贝了所有安装包.
pip 各种包的兼容性简直稀烂, 搞机器学习很多时候非常痛苦, 同样的包, 同样的版本, 换台机器安装就不能运行了, 甚至同样的版本依赖库, 换个操作系统安装后, 就直接报错, 特别是在 Windows 下.
shyling
2022-08-03 15:25:50 +08:00
@wxf666 emmmm 你研究下 virtualenv 吧
wxf666
2022-08-03 15:48:50 +08:00
@shyling 你直接说会碰到啥问题吧,搞得讳莫如深的样子
dcsuibian
2022-08-03 16:21:07 +08:00
@whusnoopy
npm 没有啥虚拟空间吧,就算 cd 进对应文件夹,which npm 和 which node 的结果也是一样的。
但 python 的虚拟环境激活后,which python 结果就不一样了(虽然也是个软链接),是伪全局。

感觉 requipments.txt 比起 package.json 还差点。npm init 的时候就创建了 package.json ,使用 npm 命令安装、更新、移除依赖还会同步更改 package.json 。
而 requirements.txt 则需要手动编写,自动导出还会弄出一些隐式存在的包。

具体实现先放一边,主要看设计思路。npm 放本地的做法明显更适合工程、项目。


按理来说,全局安装也有相应的好处。就是方便共享,对于脚本程序确实很合适。
但问题是,实操下来,python 相关库的版本兼容性问题很大,甚至 python 自己的版本也很重要。常常需要创建新的虚拟环境,这种时候全局的方式就很不实用。
dcsuibian
2022-08-03 16:37:01 +08:00
@ysc3839 Node.js 和 npm 是一体的嘛。

最好的方式其实是 Java Maven 的管理方式。
在整个机子上有一个中央仓库(.m2/repository ),里面按照坐标(组织、项目、版本)的方式存储着所有下载过的 jar 包,Java 项目只需要通过一个 pom.xml 引用,相关工具就会设置好 ClassPath 。两个项目依赖同一个库的不同版本也完全不用担心。

node_modules 这种放本地的做法,拉跨了点,但至少“两个项目依赖同一个库的不同版本”也还是没问题,只要你用的 Node.js 本身不是特别老。

但到了 Python ,两个项目依赖同一个库的不同版本就得创个新的虚拟环境了。
dcsuibian
2022-08-03 16:42:28 +08:00
@thinkershare 完全同意,这就是我搞 Python 依赖时的最大痛点。兼容性巨差。
不光是版本问题。Python 本身说是一种“跨平台”的语言,但只限于纯 Python 的情况。实际应用中很多库都是 C/C++写的,但 C/C++不是跨平台的呀。
ksc010
2022-08-03 17:07:22 +08:00
对比 node 的依赖地狱 我更喜欢 python 现在的方式,所有的包尽量用最新的版本(自己掌控的项目)。
否则就用虚拟环境,或者直接 docker 容器

@thinkershare 你举得例子 我感觉跟 pip 关系不大, 机器学习的库 好多都是和显卡驱动以及 cuda 版本绑定的
makelove
2022-08-03 17:37:54 +08:00
@dcsuibian pnpm 不就是整个机子一个中央仓库,其它都是链接
thinkershare
2022-08-03 17:47:02 +08:00
@ksc010 不只是显卡有关的包, 很多绘图的包也是.
我用过的各个语言, 个我个人的感觉 python 的包是最容易出问题, 依赖搞到奔溃, conda 有时候也解决不了问题.
node 的包就更讨厌, 但很少出问题, 基本包固定了版本, 安装一下就能跑通.
也可能是在 python 中我的使用场景问题, 因为我主要是帮朋友搞 PhD Research, 很多时候学术研究写的代码和安装包, 错误多的让人奔溃, 只能面向 GitHub 和 Stack Overflow 弄, 给作者发邮件, 作者很多时候也不回复.
janxin
2022-08-03 17:51:37 +08:00
poetry 慢不是操作的问题,是他就是很慢

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/870375

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX