Следует ли мне устанавливать conda в каждой виртуальной среде?

Я только что произвел чистую установку Anaconda3 (python 3.7) в Windows 7 и создал несколько виртуальных сред. Не пытаясь создать некоторую путаницу.

  1. В моем первом клоне базовой чистой установки нет conda и нет базовой установки в его PATH. Таким образом, единственный способ запустить conda - указать полный путь к базовой установке. Кажется неправильным.

  2. Мой python 3.5 env, созданный из файла yml, имеет в нем более старую версию conda и не имеет базового env в его PATH. Он запускает старую версию и предупреждает меня о необходимости ее обновления. Это тоже кажется неправильным.

  3. У моего последнего клона base нет conda, но он имеет базовый env на своем пути, поэтому он запускает base conda.

Третий случай так и должен быть всегда?

Как исправить первый и второй случаи?

Есть ли что-нибудь, на что мне следует обратить внимание в следующий раз, чтобы избежать первого и второго случаев?

Обновлять:

  1. Первый случай связан не с самой средой, а скорее с ярлыком меню «Пуск», который создается conda во время клонирования. Когда я открываю консоль в базе, а затем активирую эту среду, все работает нормально. Я могу жить с этим.

  2. Я создал этот yml-файл с помощью команды: conda env export -n base > file.yml в моей старой установке python 3.5. Таким образом, в файл yml включены следующие элементы, связанные с conda:

    • anaconda-clean=1.1.0=py35_0
    • анаконда-клиент = 1.7.2 = py35_0
    • анаконда = обычай = py35_0
    • анаконда-навигатор = 1.9.2 = py35_0
    • conda = 4.5.11 = py35_0
    • conda-build = 2.1.4 = py35_0
    • conda-env = 2.6.0 = h36134e3_1
    • conda-verify = 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?


python-3.x python windows conda anaconda3
person adr    schedule 17.01.2019    source источник
comment
К сожалению, я не записал свои шаги точно и заметил несоответствие только позже, но я постараюсь добавить подробности позже. Спасибо, что сообщили мне, как все должно быть.   -  person adr    schedule 18.01.2019
comment
не беспокойтесь, я точно был в подобных ситуациях. Я добавил свой комментарий в качестве ответа, так что он немного более читабелен, но не чувствую себя обязанным соглашаться, если вы хотите продержаться, возможно, более авторитетного ответа.   -  person merv    schedule 18.01.2019

Ответы (1)


arrow_upward
1
arrow_downward

Да, сценарий № 3, то есть conda только в base env, с каталогом base bin/ в PATH, кажется стандартной конфигурацией.

Когда я клонировал свою базу, т.е.

conda create -n base-clone --clone base

он предупредил меня, что пакеты conda и conda-env не будут скопированы, что привело к конфигурации, имеющейся у вас в случае № 3.

Чтобы исправить случай (2), вероятно, будет достаточно удалить conda и conda-env из YAML, а затем воссоздать env.

Не уверен насчет случая (1), хотя обычно каталог base bin/ должен находиться на PATH в большинстве установок по умолчанию, и активация другого env (клонированного или нет) не должна влиять на эту запись, а только добавляется От envs/your-env/bin/ (выше) до PATH.

Я полагаю, мне следует добавить отказ от ответственности, что все это основано на эмпирическом опыте / тестировании (с conda v4.5.12, установленным через Miniconda на MacOS 10.14), а не на каких-либо прямых знаниях о внутреннем устройстве conda.

person merv    schedule 18.01.2019