【Conda | .venv | 虚拟环境】 conda构建项目内的虚拟环境.venv以及选择项目虚拟环境的原因所在

描述

conda使用
项目内的.venv虚拟环境构建

问题

通常我们在本地工作的时候，是使用··conda create -n newName来创建新的虚拟环境，并激活该环境在该环境在下载相应的依赖工具等，然后，在下载相关依赖时候，我们必须同步写requirement.txt文件来保存该虚拟环境中所下载或者说该项目中所用到的依赖工具等，现在我们为了项目的方便，不是说我们就不写requirement文件了，而是虚拟环境跟随项目更清晰更方便，

1 传统方式

1. 激活conda的base环境conda activate base
2. 创建新的虚拟环境 conda create - n NewEnv
3. 激活该虚拟环境conda activate NewEnv
4. 根据requirement文件下载所需依赖或者自行下载所需内容 pip -r requirement.txt pip install -r requirements.txt
5. 项目使用该环境时，需要激活该环境
6. 迁移的时候不能迁移该环境

解决

在该项目中创建虚拟环境方式

1. 进入到你的项目根目录中cd ./your-project
2. 在项目当前目录下创建.venv环境 conda create -p ./.venv python=3.10. -y conda create -p ./.venv python=3.10 -y
3. 激活该路径下的虚拟环境 conda activate ./.venv

提醒！配套防坑设置

但是我们再向github等上传项目的时候，需要主要的是
虚拟环境的占用空间极大，里面全是二进制的库，绝对不可以提交到git仓库中、
所以，

1. 将 .venv 写入 .gitignore
   在项目根目录下，直接用这行命令把 .venv 忽略规则写入 .gitignore：
   echo “.venv/” >> .gitignore

2. 激活时需要带相对路径：
   在终端中激活时，不能直接敲名字**，必须加上 ./：**

-n&-p两种创建方式的核心区别

使用 -n 全局创建和使用 -p 在项目内创建，本质上是“集中式管理”与**“项目自包含（Self-contained）”**两种不同的环境管理哲学。

1. 存放位置不同。一个是在系溶剂中目录管理；另一个是在当前项目根目录下；（一个是在系统集中目录管理）
2. 激活方式不同。一个是按照名字激活；另一个是按照路径激活
3. 环境列表不同。一个是运行conda env list时候会显示环境名称；另一个是会显示的是完整路径。
4. 与项目的绑定度。一个是解耦*，即多个项目可以共用*，另一个是强绑定，是该项目的专属
5. 清理方式。集中管理的使用conda env remove -n myenv ；而另一个是直接把项目文件夹的**.venv**删掉，或者跟着整个项目目录一起删除

集中管理的思想还可以共用？为什么？为什么越来越多人喜欢在项目内构建 .venv？

在实际开发和科研中，将虚拟环境直接建在项目根目录（./.venv）有以下几个极具吸引力的优势：

1. IDE 智能识别，真正做到“开箱即用”.
   

2. 彻底摆脱“命名焦虑”与全局环境污染.
   

3. 极佳的生命周期管理（“零残留”清理）
   一个项目彻底废弃或写完需要删掉
   
   符合现代 Python 生态标准

4. 符合现代 Python 生态标准

在 Python 官方的 venv、poetry、uv 以及现代包管理体系中，把虚拟环境放在项目根目录并命名为 .venv 已经成为工业界的标准约定。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/weixin_52372189/article/details/163142739