Как заставить точки входа скрипта консоли Python работать, когда установленный пакет использует виртуальную среду conda? - PullRequest
1 голос
/ 12 октября 2019

Проблема - Переход из не виртуальной в виртуальную среду conda приводит к тому, что точки входа консольного скрипта не распознаются.

Справочная информация - Я недавно пытался получить религиюоб использовании виртуальных сред для моих проектов Python. Я решил сделать это после обновления до macOS. Каталина заставила все мои проекты PyCharm показывать ошибки недопустимого интерпретатора. Я подумал: «Что может пойти не так, если вы накинете один большой беспорядок на другой?»Через два дня я снова смог запустить сценарий - худшую кирпичную стену, которую я когда-либо бил. Мне нигде не удалось найти решение, поэтому я пишу свой первый вопрос SO и свое решение, которому следую, думая, что у меня наконец-то появится возможность внести свой вклад в этот сайт, который я так долго использовал.

Мои настройки

  • ОС: macOS Catalina
  • Оболочка: bash (да, я изменил ее обратно после обновления Catalina и подавил злобную 'zsh)теперь является сообщением по умолчанию)
  • IDE: PyCharm 19.1 Pro
  • Анаконда: 4.4.7
  • Python: 3.7

Context- Я разрабатываю несколько взаимодействующих пакетов научных данных и локально устанавливаю их в редактируемом режиме в качестве общей практики:

My_Machine:my_package my_user_name$ pip install -e .

Я создаю пакеты python с использованием файла setup.py с setuptools, собирая с помощью PyCharm. В файле setup.py я определяю точки входа консольного сценария следующим образом:

setup.py :

# -*- coding: utf-8 -*-

from setuptools import setup, find_packages

setup(...
      name='my_project',
      entry_points={'console_scripts':['my_entry_name=my_package.scripts.my_python_script:main'
                                      ]},
     ...
)

Перед переходом в виртуальную среду conda яв течение многих лет прекрасно выполнял сценарий с помощью командного файла, например:

my_batch_file.command:

#!/bin/bash
cd "$(dirname "$0")"  # set the working directory as the command file locations

my_entry_name <script arguments>

Однако после перехода в виртуальную среду condaкомандный файл выдает ошибку my_entry_name: command not found.

Все, что пытались до сих пор

  • Проверено и попытка установить, какой питон используется с помощью команды терминала which python,Я вижу, что по умолчанию используется значение /Users/my_user_name/anaconda3/bin/python, и если я делаю это из командной строки в моем проекте, я вижу /Users/my_user_name/anaconda3/envs/my_env/bin/python, отражая ожидаемую версию среды.
  • Проверено в фактическом файле точки входа в/Users/my_user_name/anaconda3/envs/my_env/bin/my_entry_name чтобы увидеть, как строка shebang указывает версию Python, которая была #!/Users/my_user_name/anaconda3/envs/my_env/bin/python
  • Попытка добавить этот shebang в начало моего файла .command
  • Много раз переустанавливал мой пакет, думаяточка входа может быть как-то не правильно зарегистрирована.
  • Много перепутано с bash против zsh, думая, что переход на zsh с помощью обновления Catalina и возврат к bash могли вызвать проблемы.
  • Попытался вернуться к работе, вернувшись из виртуальной среды, но не смог заставить работать настройки невиртового интерпретатора PyCharm снова.
  • Посмотрел содержимое $ PATH на предмет проблем.
  • Читать лотыучебных пособий о виртуальных средах (все, что я нашел, остановились на самых основах)
  • преследовал темы об ошибках в setuptools, связанных с виртуальной средойутюги
  • Многие комбинации этих усилий.

Ничего из этого не сработало - та же самая ошибка my_entry_name: command not found. Чрезвычайно расстраивает два дня.

Ответы [ 3 ]

0 голосов
/ 14 октября 2019

Вам не нужно активировать виртуальные среды Python, никогда, даже не один раз. Скажем, у вас есть виртуальная среда на /venv, тогда вы можете позвонить /venv/bin/python или /venv/bin/my_entry_name из любого местав любое время без активации виртуальной среды, и она должна прекрасно работать. Если это не работает, значит что-то не так с вашей настройкой, и это нужно исправить.

Когда вы используете setuptools console_scripts точки входа полный путь кинтерпретатор Python в виртуальной среде жестко запрограммирован в shebang , поэтому не должно быть никакого способа, чтобы это не работало.


Обновление

Мой плохой, я не зарегистрировал, что вы работаете с conda виртуальными средами. Я не знаю, как это работает, возможно, моя точка зрения все еще верна, но, вероятно, нет.

0 голосов
/ 17 октября 2019

Пересмотренный ответ после дальнейшего ввода и экспериментов. Я нашел два варианта, где оба требуют знания, где находится фактический файл, который определяет точку входа. Для виртуальной среды conda это будет здесь:

/anaconda3/envs/my_env_name/bin/entry_point_name

Нет необходимости указывать версию Python или активировать среду, если этот файл вызывается. Я нашел два способа сделать это:

Вариант 1 - Кредит @sinoroc, который первым указал, что виртуальную среду не нужно активировать, если точка входа вызывается правильно. Для виртуальной среды conda это будет:

my_batch_file.command

#!/bin/bash
cd "$(dirname "$0")"  # set the working directory as the command file locations

~/anaconda3/envs/my_env_name/bin/entry_point_name <my script args>

Для других типов виртуальных сред вы просто откорректируете детали пути, чтобы получитьк файлу точки входа.

Вариант 2 - Если вы поместите копию файла точки входа в основную корзину Anaconda:

/anaconda3/bin/my_entry_name

вы не сделаетенужно указать путь, позволяющий вам вызывать точку входа так, как они должны работать, imho - т.е. защищает пользователя скрипта от языка и деталей установки:

my_batch_file.command

#!/bin/bash
cd "$(dirname "$0")"  # set the working directory as the command file locations

entry_point_name <my script args>

Поскольку этот шаг копирования вручную не является элегантным, я разместил вопрос о том, как сделать это лучше: Как сделать точку входа в сценарий в виртуальной среде доступной для всей системы?

0 голосов
/ 12 октября 2019

После двух дней борьбы, я нашел решение, которое я опубликую ниже, однако мне очень хотелось бы услышать комментарии, альтернативы и прямую школу «ты идиот».

Кажется, необходимы два элемента:

  • Указание версии Python для использования в качестве версии, связанной с виртуальной средой (как я пытался безуспешно).
  • Активация виртуальной среды.

Я изменил свой файл .command на это, добавив несколько ненужных проверок проверки версии python до и после ее указания и связанного с ней вывода текста:

my_batch.command:

#!/usr/bin/env bash

echo "VERIFY: Python version BEFORE activating virtual environment:"
which python

echo "Activating conda virtual environment..."
source activate my_env_name

echo "Setting python version to use in this environment..."
#!/Users/my_username/anaconda3/envs/my_env_name/bin/python

echo "VERIFY: Python version AFTER activating virtual environment:"
which python

cd "$(dirname "$0")"  # set the working directory as the command file locations

echo "RUN THE SCRIPT:"
my_entry_name <script arguments>

Ключевой строкой, которую я пропустил, была source activate my_env_name. Я проверил, что удаление этого приводит к сбою, и это должно быть включено каждый раз, а не только один раз, таким образом, включено в мой файл .command.

Мне также не было ясно, что было бы нормально иметь несколько строк Шебанга, но это сработало нормально.

Я рад, что снова функционирую, но должен признать, что разочарован тем, что архитектура не просто заставляет мою точку входа работать, и точка, без этой грубости. Причина для того, чтобы иметь точку входа, состоит в том, чтобы позволить потребителю скрипта легко вызывать его, и не нужно заботиться о таких деталях, как, где находится скрипт и как он установлен. Использование виртуальной среды, кажется, устраняет эти удобства точки входа. Я за преимущества использования виртуальных сред, но есть ли какой-нибудь способ съесть свой пирог и съесть его тоже? В идеале вызов точки входа активировал бы виртуальную среду и знал бы, какую версию python использовать. Есть ли какой-нибудь лучший способ сделать это?

...