Python中pipenv相较于pyenv有哪些优势?
pipenv 和 pyenv+virtualenv 都可以实现特定版本的虚拟环境
pipenv 似乎还可以实现特定包的 dev 版本和 prod 版本
除了这些功能 pipenv 还有哪些优势吗?
Python中pipenv相较于pyenv有哪些优势?
pipenv shell 比 source xxx 方便多了?
Pipenv和Pyenv解决的是不同层面的问题,把它们放一起比“优势”其实不太对。简单说,Pyenv管Python版本,Pipenv管项目依赖和环境。
Pyenv就是个Python版本管理器,让你在一台机器上装多个Python版本(比如3.8, 3.9, 3.10),然后可以全局或按目录切换。它只解决“用哪个Python解释器”的问题,不管第三方包。
Pipenv的核心是依赖管理和虚拟环境。它把pip和virtualenv打包成一个工具,主要干两件事:
- 生成
Pipfile和Pipfile.lock:这比老旧的requirements.txt强多了。Pipfile区分生产环境和开发环境的依赖,Pipfile.lock锁定所有依赖的确切版本,确保环境一致。 - 自动创建和管理虚拟环境:你不需要先
virtualenv venv再source,pipenv install会自动创建关联当前项目的虚拟环境。
所以,如果你在为一个Python项目选择工具栈:
- 你需要切换不同Python解释器版本 -> 用Pyenv(或者更新的
uv)。 - 你需要管理这个项目的依赖包,并创建隔离环境 -> 用Pipenv。
实际上,它们经常一起用:用Pyenv安装某个Python版本,然后用Pipenv在这个版本下创建项目虚拟环境并装包。
现在社区有更现代的工具比如uv,它把版本管理、虚拟环境、依赖打包全干了,而且快得多。但理解Pipenv和Pyenv的分工还是很有用的。
总结:Pyenv管解释器,Pipenv管包和环境,它俩不冲突。
话说这种使用情况多吗…好像一般都是 cd 到项目目录然后再 activate virtualenv 的, pyenv 可以在项目文件夹下加.python-version, cd 进去的时候就自动 activate 了…
为什么不用 alias…
alias venv="source ~/venv/bin/activate"
alias proj="cd 项目目录"
alias t=“proj;venv”
pyenv local tensorflow2.7
可以吧目录设置成特定版本,cd 进目录自动切换环境,如下:
# kevin @ KevinMBP in ~ [13:09:26]
$ cd Tensorflow
(tensorflow2.7)
# kevin @ KevinMBP in ~/Tensorflow [14:55:18]
$ cd …/Tensorflow3
(tensorflow3.6)
# kevin @ KevinMBP in ~/Tensorflow3 [14:57:33]
$
我一直觉得 cd 到某个目录,自动切换环境这个,给人的感觉非常的混乱和不可控,我还是更喜欢手动
支持 Pipfile 和 Pipfile.lock
一个目录就下面做一件事情,这样还是比较方便的。
感觉这个和 requirements 差不多啊。。。都可以指定版本的
一个项目目录对应一个虚拟环境,在 a 目录用 b 环境才会觉得很混乱吧。。。其实我经常忘记切 virtualenv,自动切反而有帮助。。
但是 alias 并不是项目本身提供的便利功能?
#10 个人习惯吧。我也觉得 cd 到目录自动切换环境不好用,所以宁可写几个 alias。
requirements 混淆了两件事,一是你想要哪些 package,二是系统当前能运行的 package (包含所有依赖)的严格版本。
https://www.kennethreitz.org/essays/a-better-pip-workflow
再后来他就做了 Pipenv。
一个目录对应一个环境是没有问题的。主要是通过 Hack CD 命令来实现有点蛋疼,很多种情况下容易引起混乱。
我随便举几个,例如:
1,用户使用的是不同的 bash 还能不能支持?
2,当使用非当前用户登陆系统时,能不能支持?
3,软件通过命令行调用 python 脚本时,在软件执行过程中切换到这个目录还能不能支持?
4,如果有其他程序也 hack 也 CD 命令来实现对应的功能,是否会导致其中的一个不能用?
这些都很让人困惑,所以我更倾向手动切换,靠谱而让人放心
折腾过好多种环境隔离工具, 最后发现还是 virtualenvwrapper 好用

