Python 能不能像 node 一样管理包

V2EX = way to explore

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

For Existing Member Sign In

推荐学习书目

› 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

This topic created in 1364 days ago, the information mentioned may be changed or developed.

node_modules
package.json

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

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

Supplement 1 · Aug 3, 2022

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

删除

创建

JSON

Python

56 replies • 2022-08-04 17:21:10 +08:00

ranleng

Aug 3, 2022

pip install -r requirement.txt

Geekgogo

Aug 3, 2022

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

ipwx

Aug 3, 2022

virtualenv
poetry

1543544726zy

Aug 3, 2022

why not all in docker . dev and deploy .

nodewee

Aug 3, 2022

可以试试 pdm

gkiwi

Aug 3, 2022

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

Trim21

Aug 3, 2022 via Android

相关的 pep 还是 draft

dcsuibian

Aug 3, 2022

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

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

SteinsGate

Aug 3, 2022 via Android

pyenv + pyenv virtualenv + poetry

renmu123

Aug 3, 2022 via Android

poetry

whusnoopy

Aug 3, 2022

@dcsuibian #8

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

oncethink

Aug 3, 2022

PEP 582 就是在解决这个问题

ratazzi

Aug 3, 2022 via iPhone

请看 conda 文档，不要乱讲

shyling

Aug 3, 2022

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

ChrisFreeMan

Aug 3, 2022

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

anxn

Aug 3, 2022

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

Vegetable

Aug 3, 2022

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

fgwmlhdkkkw

Aug 3, 2022

pip install -t ./deps

wxf666

Aug 3, 2022

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

ysc3839

Aug 3, 2022 via Android

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

wxf666

Aug 3, 2022

@yuhangch ，最基础的 virtualenv 都能支持项目级依赖啊，Pycharm 默认的虚拟环境就是这货

cherryas

Aug 3, 2022

有没有可能 python 不 import 就等于 node 不装依赖

dcoder

Aug 3, 2022

@yuhangch
用 poetry 啊

wdhwg001

Aug 3, 2022

poetry 是一个基于 venv 的依赖安装工具。
pdm 是一个可以基于 venv 也可以在文件夹内安装依赖的工具。

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

pdm 诞生于这些 PEP 出现后，所以它天生就支持这些新的 PEP 。

wdhwg001

Aug 3, 2022

补充：pdm 提供了 poetry 格式的兼容转换，而 poetry 则没有提供。

另外 pdm 的开发者是国人，这一点或许可以影响一小部分判断。但 pdm 的质量实际上比早期 poetry 的质量强多了，用过早期 poetry 的都知道它有多少莫名其妙的小 bug 。

qbug

Aug 3, 2022

@1543544726zy container 大法好！不过 docker 貌似已经不太行了，不但被巨头打压，自己的也没做得太好，podman 确实香。

shyling

Aug 3, 2022

@wxf666 依靠环境变量啊

yedanten

Aug 3, 2022 via Android

node 的依赖管理就是噩梦，竟然还想复刻

supercaizehua

Aug 3, 2022

据说 pdm 挺好用的

wxf666

Aug 3, 2022

@shyling 依靠什么环境变量？即使不 source <venv>/bin/activate ，直接运行 .py 文件也没问题啊

thinkershare

Aug 3, 2022

一些包这么搞可能没问题, 但很多 Python 包, 你换一个环境, 根本没法运行, 即便你拷贝了所有安装包.
pip 各种包的兼容性简直稀烂, 搞机器学习很多时候非常痛苦, 同样的包, 同样的版本, 换台机器安装就不能运行了, 甚至同样的版本依赖库, 换个操作系统安装后, 就直接报错, 特别是在 Windows 下.

shyling

Aug 3, 2022

@wxf666 emmmm 你研究下 virtualenv 吧

wxf666

Aug 3, 2022

@shyling 你直接说会碰到啥问题吧，搞得讳莫如深的样子

dcsuibian

Aug 3, 2022

@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

Aug 3, 2022

@ysc3839 Node.js 和 npm 是一体的嘛。

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

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

但到了 Python ，两个项目依赖同一个库的不同版本就得创个新的虚拟环境了。

dcsuibian

Aug 3, 2022

@thinkershare 完全同意，这就是我搞 Python 依赖时的最大痛点。兼容性巨差。
不光是版本问题。Python 本身说是一种“跨平台”的语言，但只限于纯 Python 的情况。实际应用中很多库都是 C/C++写的，但 C/C++不是跨平台的呀。

ksc010

Aug 3, 2022

对比 node 的依赖地狱我更喜欢 python 现在的方式，所有的包尽量用最新的版本（自己掌控的项目）。
否则就用虚拟环境，或者直接 docker 容器

@thinkershare 你举得例子我感觉跟 pip 关系不大，机器学习的库好多都是和显卡驱动以及 cuda 版本绑定的

makelove

Aug 3, 2022

@dcsuibian pnpm 不就是整个机子一个中央仓库，其它都是链接

thinkershare

Aug 3, 2022

@ksc010 不只是显卡有关的包, 很多绘图的包也是.
我用过的各个语言, 个我个人的感觉 python 的包是最容易出问题, 依赖搞到奔溃, conda 有时候也解决不了问题.
node 的包就更讨厌, 但很少出问题, 基本包固定了版本, 安装一下就能跑通.
也可能是在 python 中我的使用场景问题, 因为我主要是帮朋友搞 PhD Research, 很多时候学术研究写的代码和安装包, 错误多的让人奔溃, 只能面向 GitHub 和 Stack Overflow 弄, 给作者发邮件, 作者很多时候也不回复.

janxin

Aug 3, 2022

poetry 慢不是操作的问题，是他就是很慢

towave

Aug 3, 2022

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

786375312123

Aug 3, 2022

requirement.txt

LoNeFong

Aug 3, 2022

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

jiazhoulvke

Aug 3, 2022

居然有人喜欢黑洞

u823tg

Aug 3, 2022

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

u823tg

Aug 3, 2022

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

lisongeee

Aug 3, 2022

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 就行