«setup.py development» устанавливает удаленную версию git вместо локальной с живыми изменениями

Question

Обычно, когда я разрабатываю пакет Python для личного использования, я использую python3 setup.py develop, а затем выполняю pip3 install -e <path_to_package> в рамках другого virtualenv, что позволяет мне одновременно работать с обоими. Когда я делаю gpip3 freeze, я вижу путь к пакету на моей локальной машине:

-e /Users/myName/Documents/testpackage

Когда я сохраняю этот пакет на GitHub и клонирую его обратно на локальную машину, я ожидаю, что смогу использоватьsetup.py develop и продолжайте разработку пакета на моей локальной машине, независимо от того, когда я вернусь в GitHub. Однако, когда я делаю gpip3 freeze, я вижу:

-e git+git@github.com:github_username/repo_name@-----latest_commit's_sha_code-----#egg=repo_name&subdirectory=xx/xx/testpackage

Я бы хотел, чтобы моя система отслеживала локальную версию, а не удаленную для git.

Примечание: я знаю, какпередайте и внесите локальные изменения в GitHub и установите яйцо в локальной среде. Моя цель - быстро протестировать идеи с помощью версии пакета для разработки без непрерывной интеграции.

Примечание 2. Сбой адреса GitHub, указанного в gpip3 freeze, при попытке его выполнить в среде (FileNotFoundError: [Errno 2] No such file or directory: '/Users/myName/Documents/testenvironment/src/testpackage/setup.py')

Но если бы я хотел, чтобы pip3 установил последний коммит GitHub, я бы не стал беспокоиться о setup.py develop в любом случае.

Есть ли способ сообщить в setup.py, что я хочу, чтобы он игнорировал пульт в клонированном репо и обращал внимание только на локальный путь? Или всегда ссылается на пульт, когда присутствует ожидаемое поведение инструментов настройки?

обновление: формулировка вывода в gpip3 freeze после python3 setup.py develop, когда пульт отсутствует (ниже), заставляет меня задуматьсячто отслеживание пульта дистанционного управления, когда это возможно, может быть предполагаемым поведением:

# Editable Git install with no remote (testpackage ==0.0.1)
-e /Users/myName/Documents/testpackage

Я работал над этим git remote remove origin, когда я хочу, чтобы мои локальные изменения отражались в локальных средах, не нажимая новый коммит, хотядля меня.

Answer 1

Мой вопрос был связан с неправильным пониманием того, как реализовать python3 setup.py develop.

Мой оригинальный метод был:

1) python3 setup.py develop из самого каталога пакета, который установил бы/ связать яйцо глобально

2) gpip3 freeze, чтобы получить (как мне показалось) ссылку на яйцо (просмотр всей дополнительной удаленной информации о git меня здесь смущает)

3) cd в другую виртуальную среду, source bin/activate, затем вызовите pip3 install -e <link_copied_from_global_pip_freeze>

Фактически нет необходимости вызывать python3 setup.py develop из разрабатываемого пакета или использовать gpip3 freeze, чтобы получить яйцоссылка.

Я могу перейти непосредственно к виртуальной среде и активировать ее, затем использовать pip3 install -e <system_path_to_package_directory_containing_setup.py>. Это создаст ссылку на яйцо в каталоге пакета, если он еще не существует. Изменения в пакете отражаются в виртуальной среде, как и ожидалось, и я могу свободно использовать контроль версий Git внутри пакета в соответствии с моими потребностями без помех.

Я предполагаю, что может быть время для прямого вызова python3 setup.py develop (setup.py develop --user также существует), но не делая этого, я избегаю засорять свою глобальную среду дополнительными пакетами.

Информация, связанная с вопросом 2014 года, в потоке Python Disutils :

Спрашивающий пишет:

В течение многих лет я рекомендовал:

$ python setup.py develop

[...]

Сказав это, я также заметил, что:

$ pip install -e.

делает то же самое.

Должен ли я рекомендовать одно из другого?

Ноа отвечает:

Вы должны порекомендовать использовать для него pip, в основном потому, что, как вы сказали, это будет работать даже с пакетами, которые не используют setuptools :-) Это такжетребуется при выполнении разработки с extras, хотя для этого требуется немного более подробный синтаксис из-за ошибки в pip.