pip - указать версию для скачивания на основе доступной версии библиотеки - PullRequest
Новая
       75

pip - указать версию для скачивания на основе доступной версии библиотеки

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

Я разрабатываю пакет Python my_package, который зависит от какого-то другого пакета foo_package.

Существует несколько версий foo_package, которые используются в сообществе, и, к сожалению, это не так. обратно совместимы друг с другом. (Из-за изменений в интерфейсе C, с которыми скомпилирован мой код).

Поэтому я хотел бы распространить несколько копий my_package, соответствующих различным версиям foo_package.

Я могу отличить эти разные копии my_package друг от друга, используя теги после выпуска. Например, я могу дать my_package версию 1.1.4-foo_package1.2, соответствующую версии 1.1.4 из my_package, скомпилированной с версией 1.2 из foo_package.

Пока все хорошо. Предостережение заключается в том, что когда дело доходит до установки этого с pip, конечные пользователи должны указать эту строку полной версии, чтобы иметь возможность получить правильную версию my_package. То есть они должны знать, что последний выпуск my_package - это 1.1.4, а используемый ими выпуск foo_package - 1.2, и, следовательно, использовать команду pip install my_package==1.1.4-foo_package1.2.

* 1029. * Очевидно, что это не идеально для всех видов причин. (Удобство для конечного пользователя, избегая адской зависимости ...) В конце концов, все это можно определить программно!

Есть ли какой-нибудь разумный способ справиться с этой проблемой, чтобы конечный пользователь мог просто запустить pip install my_packageи правильно ли загружена правильная копия?

Есть один неудовлетворительный ответ на аналогичный вопрос здесь .

FWIW лучшее решение, которое я до сих пор придумалсоздать еще один пакет my_package_installer, который как часть его setup.py проверяет, какая версия foo_package установлена, а затем указывает соответствующую версию my_package в качестве аргумента install_requires для setuptools.setup. Но это совершенно глупо и кажется довольно хрупким. Я не могу быть единственным с этой проблемой.

Ответы [ 2 ]

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

А как насчет создания нескольких проектов Python из одной базы кода?

Допустим, у вас есть хранилище исходного кода MyProject.git, и вы хотите распространить его для libfoo1.2 и libfoo1.4. Тогда, может быть, setup.py, который выглядит следующим образом, поможет: 

#!/usr/bin/env python3

import distutils.core
import setuptools

def get_foo_version():
    return '1.2' if True else '1.4'

foo_version = get_foo_version()

foo_module = distutils.core.Extension(
    'foo',
    define_macros=[('FOO_VERSION', foo_version)],
    libraries=['foo{}'.format(foo_version)],
    sources=['foo.c'],
    # ...
)

setuptools.setup(
   name='MyProjectForFoo{}'.format(foo_version),
   ext_modules = [foo_module],
   # ...
)

В этом сценарии вы получите два проекта Python MyProjectForFoo1.2 и MyProjectForFoo1.4. Пользователям вашего проекта все равно придется выбирать правильный проект, но он будет менее подвержен путанице, чем сортировка по номерам версий.

Возможно, вы могли бы использовать tox и / или хорошийСистема CI / CD, помогающая автоматизировать создание и публикацию дистрибутивов ( wheel ) для двух (или более) проектов.

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

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

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

...