- conda 创建虚拟环境，此时，conda list为空， pip list 为本机pip list
2.
conda install python=3.9
之后 ，pip list 与conda list相同，均为python与相关依赖包
3.
conda install fake-useragent==0.1.11
conda 可以安装anaconda上拥有的包（大约有一千多个） ，但是有些包anaconda不存在，以fake-useragent(0.1.11)为例
若安装会出现：
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
PackagesNotFoundError: The following packages are not available from current channels:
- fake-useragent==0.1.11
Current channels:
- https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/win-64
- https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/noarch
- https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r/win-64
- https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/r/noarch
- https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2/win-64
- https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/msys2/noarch
To search for alternate channels that may provide the conda package you're
looking for, navigate to
https://anaconda.org
and use the search bar at the top of the page.
所以此时我们想用pip install
pip install fake-useragent=0.1.11
pip安装没有的包
安装后，打开conda list 与pip list
我们会发现，两个list之中均与该包
截图如下：
conda list: fake-useragent 在最底下
pip list: fake-useragent 在最底下
若是使用conda install 安装的包，则同样 在两个list中均存在
- 我们在该虚拟环境下import 用 pip install 的包，可以成功的import
总结：
pip install 可以安装anaconda没有的包，包同时在两个list中出现，而且在虚拟环境中可以正常import。
conda 虚拟环境中，pip list 确实是 conda list 的真子集。
Original: https://blog.csdn.net/m0_60235585/article/details/125794763
Author: 钠文
Title: conda虚拟环境 | install 与 list 问题
相关阅读
Title: Argo CD系列视频图文版之自建应用模拟开发场景
开篇
本期视频，我们来动手自建一个应用，模拟实际的场景。通过这个场景模拟，各位可以感受到真正生产环境中应该怎样使用 ArgoCD。我们的项目托管在 Github，留作给大家作为参考材料。
argocd in action[1]
配套视频
flask demo
flask demo 目录用来模拟代码仓库，它是一个典型极简的 Flask 项目，主要功能就是输出数据库连接的环境变量到前端页面。
注：此处仅为模拟功能，将实际生产环境拉至祭天。
[En]
Note: here is only the simulation function, the actual production environment will be pulled to sacrifice to heaven.
.
├── Dockerfile
├── Makefile
├── app.py
└── requirements.txt
我们可以通过 make image 命令在本地 build 一个镜像。我已经打包好一个镜像： 364950776/flask-demo:latest
kustomize
kustomize 目录用来编写应用的配置清单，同样的，这也是一个典型极简的 kustomize 支持的配置目录。
具体 kustomize 的用法此处不再赘述，值得一提的是，deployment 中的环境变量，是通过 configMapGenerator 注入的。这是 kustomize 的一个特性，环境变量都存储在 envs.yaml 中。
.
├── deployment.yaml
├── envs.yaml
├── kustomization.yaml
├── namespace.yaml
└── service.yaml
添加代码仓库
注: 由于我们 github 中代码仓库是开放的，只需要添加地址即可，如果是私有仓库，需要额外添加认证信息。
部署自建应用
部署应用非常简单，在 UI 界面上填写配置即可。
发现问题
问题 1
业务源代码和部署列表在同一仓库，功能权限不够明确。源代码是开发团队关心的问题，部署是运营团队关心的问题。记录提交混乱，审计困难。
[En]
The business source code and deployment list are in the same warehouse, and the functional permissions are not clear enough. The source code is the concern of the development team, while the deployment is the concern of the operations team. The submission of records is confused and the audit is difficult.
所以 ArgoCD 官方强烈建议，业务源码和部署清单，分两个仓库存储。
问题 2
业务源码和部署清单，分两个仓库存储。每次源码发布新版本，开发人员都要手动打包镜像，再通知运维修改部署清单中的镜像，最后运维登录 ArgoCD 界面同步应用状态。
这一操作完全是低效的，没有完全自动化上述过程的自动方案。
[En]
This operation is completely inefficient, there is no automatic scheme to fully automate the above process.
结束语
虽然我们顺利地完成了对自建应用的 gitops 实验，但这并不是最佳实践，仍然有两个问题需要我们解决。下节课，咱们就来解决这两个问题。
参考资料
[1]
argocd in action: https://github.com/pyfs/argocd-in-action
Original: https://blog.csdn.net/u014249394/article/details/122183527
Author: LinuxSuRen
Title: Argo CD系列视频图文版之自建应用模拟开发场景
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/333228/
转载文章受原作者版权保护。转载请注明原作者出处！
