Python中为什么有人推荐pipenv,但实际使用体验很差?
lock 好久好久,install 个东西还时不时的失败,这种项目怎么还能有人推荐
Python中为什么有人推荐pipenv,但实际使用体验很差?
是不是你用的方法有问题呀亲
pipenv的问题主要是依赖解析慢和锁定时间长,特别是项目依赖复杂的时候。它试图把pip和virtualenv打包成一个工具,但实际用起来反而更重。
现在更推荐用poetry或者直接pip+venv。poetry的依赖解析快得多,而且pyproject.toml的配置方式更现代。如果项目简单,直接用python自带的venv创建虚拟环境,然后用pip安装依赖反而最直接。
总结:换poetry或回归pip+venv吧。
不要用 Pipenv site:zhihu.com
不能直接发链接,搜这个,第一条
我现在确定用法没问题,github 上搜一下一堆一堆类似的 isssue,你用着很爽?
好吧,为时已晚啊
pipenv 很烂,我们现在用 poetry,相对好点
这个怎么样,有明显的硬伤吗
这段时间是有一波节奏从 pipenv 转 poetry 的
反正我平时小项目 pipenv 没什么问题, 至于 lock 时间太长, 有的时候可以 ignore lock, 另外… 一般依赖没改变的情况还真没用过 pipenv install, 也就不存在被它拖时间的情况了, 有人推荐是因为省事, 而且也没什么其它简单选择啊, poetry 就算再好, 就算支持捎带发布 twine pypi 什么的, 还是感觉有学习成本, pipenv 的成本就是 pipenv run…
不用 pipenv install,新包怎么安装呢?依赖老也不改变,我管理个啥,问号脸,这个工具存在不就是为了管理这些包的么。所以你的逻辑是,如果不怎么用它,那它还可以。???
还是说我理解错你说的依赖了
之前有一段时间同时使用 pioenv 和 poetry,这段时间尝试了一下 pipenv,还是用回 poetry 了。
poetry 比 pipenv 在各种角度上好用很多,就比如他 readme 里面提到的,为什么要同时维护一个 requirements,还要维护两个 pipenv 的文件,这几个文件本来不就应该保持同步么,难道你的项目中依赖于 requests=1 你会安装一个 requests=2 在环境中吗。
我习惯用 windows 开发,然后打包成 docker 放到 linux 服务器上去,或者用 windows 开发,打包在三个平台上使用,这个使用场景 pipenv 似乎完全没考虑。
poetry 生成的 lock 是跨平台的,也就是说你在 windows 下面生产的 lock 文件不需要担心在 linux 下面会生成不一样的 lock 文件(当然换行符的问题还是存在)。
poetry 在安装依赖的时候,就像他的 readme 一样,会保证你安装的依赖没有版本冲突问题,但 pipenv 就是单纯的像 pip 一样安装所有依赖,然后把版本写死而已。参照 https://github.com/sdispater/poetry/blob/master/README.md#dependency-resolution 这一点似乎 poetry 是现在唯一的工具会解决这个问题。
至于学习成本,其实 poetry 也有 run 命令,就是 pipenv run 换成 poetry run。
但 poetry 没法帮助解决你解析依赖用时很长的问题,poetry 前几次解析依赖也巨慢而且经常失败,我当初就是被这个劝退。
不过在成功运行并把需要的数据缓存到本地之后情况就好多了。
谢谢,不过有一个问题指出下:在不需要的情况下,pipenv 是不需要维护 requirements 文件,pipfile 和 pipfile.lock 就可以了。我没用过 poetry,不过就我使用 pipenv 的体验来说,它在各方面的设想都没有什么问题,只是这个 lock 失败真的是蛋疼死。。。
#12 因为我要打包传到 pypi 上面去, 所以我需要维护一个 requirements 文件…更新了两次依赖版本就弃用了, 都没等到用在不需要维护 requirements.txt 的项目上
poetry 最近发了 1.0.0, 不如尝试一下 

