1

我刚刚在 Windows 7 上全新安装了 Anaconda3 (python 3.7) 并创建了几个虚拟环境。没有尝试，我造成了一些混乱。

  1. 我的基本全新安装的第一个克隆没有conda，并且在其 PATH中没有基本安装。因此，运行 conda 的唯一方法是指定基本安装的完整路径。似乎错了。

  2. 我从 yml 文件创建的 python 3.5 env 中包含旧版本的 conda，并且在其 PATH 中没有基本 env。它运行旧版本并警告我更新它。好像也错了。

  3. 我最近的 base 克隆没有 conda 它，但它的路径中确实有 base env，所以它运行基本 conda。

第三种情况是否应该始终如此？

如何解决案例一和案例二？

下次有什么需要注意的，以避免情况一和二吗？

更新：

  1. 第一种情况与环境本身无关，而是与 conda 在克隆期间创建的开始菜单快捷方式有关。当我在基地打开一个控制台，然后激活这个环境时，一切正常。我可以忍受这一点。

  2. 我使用以下命令创建了这个 yml 文件：conda env export -n base > file.yml在我的旧 python 3.5 安装中。所以在 yml 文件中包含了以下与 conda 相关的项目：

    • 蟒蛇清洁=1.1.0=py35_0
    • 蟒蛇客户端=1.7.2=py35_0
    • 蟒蛇=自定义=py35_0
    • 蟒蛇导航器=1.9.2=py35_0
    • 康达=4.5.11=py35_0
    • conda-build=2.1.4=py35_0
    • conda-env=2.6.0=h36134e3_1
    • 康达验证=2.0.0=py35_0
    • nb_anacondacloud=1.2.0=py35_0
    • nb_conda=2.0.0=py35_0
    • nb_conda_kernels=2.0.0=py35_0

那么问题的开放部分是：上面列出的哪些与conda相关的项目不应该在python 3.5环境中？

4

1 回答 1

1

是的，场景＃3，即conda仅在基本环境中，基本 bin/目录PATH似乎是标准配置。

当我克隆我的基地时，即

conda create -n base-clone --clone base

它警告我conda和conda-env包不会被复制，这会导致您在案例 #3 中的配置。

要修复案例 (2)，可能从 YAML中删除conda和conda-env就足够了，然后重新创建 env。

不确定情况（1），尽管通常情况下，基本 bin/目录应该PATH在大多数默认安装中打开，并且激活另一个环境（无论是否克隆）不应该影响该条目，而只会envs/your-env/bin/在PATH.

我想我应该添加免责声明，这一切都来自经验/测试（在 MacOS 10.14 上通过Miniconda安装了 conda v4.5.12），而不是对 conda 内部结构的任何直接了解。

于 2019-01-18T19:57:04.127 回答