Как включить git зависимости в setup.py для установки pp

Мне нужно включить пакеты Python, доступные через публичные репозитории Github вместе с моим пакетом Python (2.7). Мой пакет должен быть установлен с помощью pip с помощью setup.py.

До сих пор это можно было сделать с помощью dependency_links в файле setup.py:

setuptools.setup(
   name="my_package",
   version="1.0",
   install_requires=[
       "other_package==1.2"
   ],
   dependency_links=[
      "https://github.com/user/other_package/tarball/master#egg=other_package-1.2"
   ]    
)

Это все еще работает, когда пакет устанавливается с флагом --process-dependency-links, но функциональность dependency_links кажется устаревшей, поскольку:

pip install git+https://github.com/user/[email protected]#egg=my_package-1.0 --process-dependency-links

дает следующее предупреждение:

DEPRECATION: Dependency Links processing has been deprecated and will be removed in a future release.

Есть ли альтернативный способ включения зависимостей git в файле setup.py с поддержкой установки pip?

Изменить (10/17/2016), чтобы уточнить мой прецедент:

Скажем, я нашел ошибку в other_package. Я развиваю соответствующее репо на Github, исправляю ошибку и делаю запрос на тяну. Мой запрос на получение не сразу принимается (или никогда не будет, потому что пакет больше не поддерживается активно). Я хотел бы распространять my_package вместе с моей вилкой other_package и хочу, чтобы пользователи имели возможность устанавливать pip my_package без каких-либо дополнительных знаний о деталях этого требования и без необходимости предоставления каких-либо дополнительных флагов при установке. Пользователи my_package должны также иметь возможность включать my_package в качестве требования в свои собственные пакеты.

Как это может быть достигнуто с учетом совместимости с различными режимами установки (колеса, яйца, разработка,...)?

Ответ 1

Лично я бы избегал включения репозиториев git в качестве зависимостей. В сценариях, которые вы описываете, я вижу два варианта.

Если пакет не поддерживается

Если пакет не поддерживается, вы можете либо разветкить проект, либо распространить свою собственную версию, либо вы можете распространять разветвленный код как подмодуль вашего собственного кода (т.е. включать внешнюю зависимость непосредственно в ваш дистрибутивный пакет)

Лично я предпочитаю распространять свою собственную версию.

Если пакет еще не включил ваше исправление

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