Использование виртуальных сред для управления разработкой / развертыванием пакетов в Jupyterhub

Question

У меня есть пакет, который я разрабатываю для локального сервера.Мне бы хотелось, чтобы текущий стабильный выпуск импортировался в ноутбук Jupyter с использованием import my_package, а текущее состояние разработки можно импортировать (для сквозного тестирования и прочего) с import my_package_dev или что-то в этом роде.

Пакет управляется версией с помощью git.Ветвь master содержит стабильный выпуск, а новая ветвь разработки выполняется в ветке develop.

В настоящее время я перенес эти две ветви в две разные папки:

my_package/  # tracks master branch of repository
    setup.py
    requirements.txt
    my_package/
        __init__.py
        # other stuff

my_package_dev/  # tracks develop branch of repository
    setup.py
    requirements.txt
    my_package/
        __init__.py
        # other stuff for dev branch

MyФайл setup.py выглядит следующим образом:

from setuptools import setup
setup(
      name='my_package',  # or 'my_package_dev' for the dev version
      # metadata stuff...
     )

Я могу pip install my_package просто отлично, но мне не удалось получить что-либо, связанное с именем my_package_dev в Python.

Вещи, которые я пробовал

• pip install my_package_dev

  Кажется, не перезаписывает существующий my_package, но, кажется, my_package_dev также не доступен,хотя пип говорит, что все в порядке.

• pip install -e my_package_dev

  делает яйцо и помещает путь пакета разработки в easy-install.pth, но я не могу import my_package_dev,my_package - это все еще старое содержимое.

• Добавление файла my_package_dev.pth в каталог site-packages и заполнение его /path/to/my_package_dev

  не вызывает видимых изменений,Все еще не позволяет мне import my_package_dev.

Мысли о решении

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

Answer 1

Ответ, предоставленный Гонсало, поставил меня на правильный путь: использовать виртуальные среды для управления двумя разными сборками.Я создал виртуальную среду для основной (стабильной) ветви с:

$ cd my_package
$ virtualenv venv  # make the virtual environment
$ source venv/bin/activate
(venv) $ pip install -r requirements.txt  # install everything listed as a requirement
(venv) $ pip install -e .  # install my_package dynamicially so that any changes are visible right away
(venv) $ sudo venv/bin/python -m ipykernel install --name 'master' --display-name 'Python 3 (default)'

И для ветви разработки я выполнил ту же процедуру в своей папке my_package_dev, присвоив ей другие --name и --display-name значение.

Обратите внимание, что мне нужно было использовать sudo для последней команды ipykernel install, потому что я продолжал получать ошибки об отказе в разрешении в моей системе.Я бы порекомендовал сначала попробовать без sudo, но для этой системы ее необходимо было установить для всей системы.

Наконец, чтобы переключаться между версиями инструментов, которые я использую, мне просто нужно выбрать Kernel -> Change kernel и выберите Python 3 (default) или Python 3 (develop).Импорт остается прежним (import my_package), поэтому ничего в записной книжке не должно меняться.

Это не совсем мой идеальный сценарий, так как это означает, что мне тогда придется повторно- запускать весь ноутбук каждый раз, когда я меняю ядра, но это работает!

Answer 2

С помощью pip install вы устанавливаете пакеты по имени в атрибуте name файла setup.py.Если вы установили оба и выполните pip freeze , вы увидите оба пакета в списке.Какой код доступен, зависит от того, как они включены в путь Python.

Проблема в том, что эти два пакета содержат только модуль python с именем my_package , поэтому вы не можете импортировать my_package_dev (он не существует).

Я бы предложил вам иметь рабочую копию для каждой версии (без изменения имени пакета) и использовать virtualenv , чтобы сохранить изолированную среду (одна virtualenv для стабильной версии, а другая для dev).Вы также можете использовать редактируемую установку pip для обновления среды с рабочими копиями.

Примечание: Переименование каталога my_package_dev my_package модуля my_package_dev в my_package_dev также будет работать.Но будет сложнее объединить изменения из одной версии в другую.