Python 能不能像 node 一样管理包

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

推荐学习书目

› 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

这是一个创建于 830 天前的主题，其中的信息可能已经有所发展或是发生改变。

node_modules
package.json

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

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

第 1 条附言 · 2022-08-03 15:49:12 +08:00

感谢各位，试了 poetry 和 pdm ，poetry 各种操作有点慢，不知道是不是操作的问题，先用 pdm 了，观察一下

删除

创建

JSON

Python

56 条回复 • 2022-08-04 17:21:10 +08:00

ranleng

2022-08-03 10:48:20 +08:00

pip install -r requirement.txt

Geekgogo

2022-08-03 10:50:02 +08:00

virtualenv 不就多一个手动创建虚拟环境的步骤嘛？项目依赖都在同一个目录下的 venv 中

ipwx

2022-08-03 10:51:38 +08:00

virtualenv
poetry

1543544726zy

2022-08-03 10:55:02 +08:00

why not all in docker . dev and deploy .

nodewee

2022-08-03 10:58:01 +08:00

可以试试 pdm

gkiwi

2022-08-03 10:59:05 +08:00

pdm： https://github.com/pdm-project/pdm

Trim21

2022-08-03 11:34:22 +08:00 via Android

相关的 pep 还是 draft

dcsuibian

2022-08-03 11:34:51 +08:00

这是我感觉 python 拉跨的地方之一，npm 再差至少一开始也有 package.json
python 要装就全局装，没有项目级依赖，pyenv 和 conda 也只是虚拟了一个全局环境（没用过 pdm ），感觉更像 nvm

不过从另一方面来说应该又与 python 的应用场景有关，因为 python 与 C/C++深度结合
我个人 pyenv 用得少，基本都用 conda 。
像 geos 、torch 这种，其实不光是 python 的版本要管理。

SteinsGate

2022-08-03 11:46:38 +08:00 via Android

pyenv + pyenv virtualenv + poetry

renmu123

2022-08-03 11:53:45 +08:00 via Android

poetry

whusnoopy

2022-08-03 12:00:11 +08:00

@dcsuibian #8

Python 有 requirements.txt 啊，pyenv 和 conda 更像 nvm ，但 virtualenv 是跟 npm 一样在虚拟空间里的，只是 npm 如果不加 -g 默认是本地，加了 -g 才全局，而 Python 是默认全局，如果激活了 virtualenv 就是本地

oncethink

2022-08-03 12:32:33 +08:00

PEP 582 就是在解决这个问题

ratazzi

2022-08-03 12:46:31 +08:00 via iPhone

请看 conda 文档，不要乱讲

shyling

2022-08-03 12:57:46 +08:00

@whusnoopy 但是 requirements.txt 是装全局的。。venv 也是伪装版的全局。

ChrisFreeMan

2022-08-03 12:58:28 +08:00

@Trim21 有段时间一直盯着这个 pep ，我觉得挺好的一个特性，貌似大家都不怎么上心。

anxn

2022-08-03 13:09:03 +08:00

为啥还有人想用 node 的灾难依赖

Vegetable

2022-08-03 13:10:47 +08:00

poetry 和 pipenv 之类的都一样啊，搜一搜很多的

fgwmlhdkkkw

2022-08-03 13:17:13 +08:00

pip install -t ./deps

wxf666

2022-08-03 13:24:57 +08:00

@shyling 『伪装版的全局』是啥意思？我在一个 venv 里安装包，会有文件装到这个目录外面？

ysc3839

2022-08-03 13:26:07 +08:00 via Android

@dcsuibian #8 Node.js 本身不会管 package.json 吧？只是默认会从 node_modules 文件夹下加载 module 。
那 Python 的问题就变成了“默认不会去本地的某个文件夹下加载 module”。对于这个问题，Python 至今也没有改变。替代方案有手动修改 sys.path ，或者使用 venv 。

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 via Android

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 慢不是操作的问题，是他就是很慢

towave

2022-08-03 18:41:50 +08:00

@dcsuibian cd 进对应文件夹，which npm 和 which node 的结果也是一样的，这个可以使用 https://github.com/volta-cli/volta 解决

786375312123

2022-08-03 19:00:44 +08:00

requirement.txt

LoNeFong

2022-08-03 19:39:01 +08:00

node 能不能像 python 一样管理包？

jiazhoulvke

2022-08-03 19:43:10 +08:00

居然有人喜欢黑洞

u823tg

2022-08-03 19:58:10 +08:00

@thinkershare #39 学术相关的基本就 c/c++，python 用来包皮的多。建议直接用 linux 。用 windows 的话装 vs 把 c++相关的全装上可以避免很多问题。剩下的就真是依赖问题了。固定下版本应该就可以。以前帮 PhD 朋友搞过。

u823tg

2022-08-03 20:00:37 +08:00

@thinkershare #39 要么就下载.whl 包。人家构建好的，别用 pip 从源码开始构建

lisongeee

2022-08-03 20:22:58 +08:00

node_modules 是有黑洞缺点，但是却解决了《单个项目直接或间接依赖了同一个库的不同版本》的问题

就是项目存在这样的依赖结构，这基本上是每个项目必现的问题
[email protected]
[email protected]
[email protected]

[email protected] 相对 [email protected] 发生完全破坏性更改，如何让 [email protected] 和 [email protected] 同时在这个项目正常工作？

除了 npm/pnpm/yarn 这类 node 包管理器，还有 deno ，我就没见过《天然支持》多版本共存的依赖管理工具

另外 npm/yarn 以及 python 的 pip/pipenv/poetry 还有 java 的 maven/gradle 都存在依赖提升的问题，导致了你虽然只在项目声明了 A 包，但是你却可以直接使用 A 的依赖

比如 python 的 requests 依赖了 certifi ，你使用 pip 安装 requests 之后，你可以在你的项目里 import requests
也可以 import certifi ，但是这是不规范的，你只安装了 requests ，按理说应该只能 import requests ，不能使用 certifi
因为你没有显式声明或者安装

比如 java 的 com.blankj:utilcodex:1.31.0 这个包，它依赖了 com.google.code.gson:gson:2.8.5 ，当你在项目里声明这个包的依赖，虽然你的项目没有声明 com.google.code.gson:gson:2.8.5 但是你却可以直接使用 gson ，这就是依赖提升，
另外假设坏的情况下你的项目还有某个包依赖了 [email protected] ，它使用了 [email protected] 的一个 A 类，但是这个 A 类在 gson@2 里面没有，你不是得手动解决？ maven/gradle 能自动解决这个问题吗？

但是 node_modules + pnpm 下这些问题都不存在，开发者不需要手动改 sys 或者额外弄个 classloader

因此对我个人而言，我基本没有遇见 node 的依赖问题，而现在我用 pnpm ，通过文件链接的方式，磁盘占用问题和依赖提升问题也得到了良好的解决

倒是我以前写 Android 的时候，老是要针对某个包 exclude ，编译老是提示某个包缺失类，但是 node 下我从来没有遇见这些问题

解决 node 的 node_modules 的黑洞问题，用 pnpm 或者 deno 就行