Re: [devel] python-requests

[Ivan Zakharyaschev <imz@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

On Fri, 6 Jul 2018, Dmitry V. Levin wrote:

> On Fri, Jul 06, 2018 at 09:05:05AM +0300, Vladimir Didenko wrote:
> > Увидел, что python-requests обновился до 2.19.1, только бомба
> > по-прежнему осталось, даже несколько. Из setup.py
> > 
> > requires = [
> >     'chardet>=3.0.2,<3.1.0',
> >     'idna>=2.5,<2.8',
> >     'urllib3>=1.21.1,<1.24',
> >     'certifi>=2017.4.17'
> > ]
> > 
> > Предлагаю сделать одно из следующих изменений:
> > 
> > 1. Поставить явные зависимости RPM с ограничениями на версию
> > (например, Requires: python-module-idna < 2.8). Спасет от мэйнтейнеров
> > chardet, idna, urllib3. Но не спасет от мэйнтейнеров, которые будут
> > обновлять python-requests вслепую, не тестируя.
> > 2. Убрать в зависимостях setup.py ограничения '<'. Я так делаю с
> > docker-compose, поскольку эти ограничения ничем не обоснованы.  Спасет
> > от мэйнтейнеров chardet, idna, urllib3, а также и от обновляющих
> > python-requests. Единственный минус - не покрывается ситуация, когда
> > при обновлении одного из пакетов совместимость действительно будет
> > сломана.
> > 3. Собирать python-requests с bundled библиотеками. Спасет всех, но c
> > идеологической сторорны выглядит не очень.
> > 
> > Лично я за пункт 2, но готов выслушать другие мнения.
> 
> Ранее уже было озвучено предложение:
> - генерить зависимости из requires[] автоматически;
> - если requires[] кривые, то патчить.

Да, так бы я и сформулировал и своё сложившееся понимание этого вопроса.

Последнее обсуждение не попало в devel@; viy@ рассказал:

----------

> Игорь, вот помните Ваше предложение по отслеживанию с помощью
> авто-reqs/provs того, что написано в *.egginfo?
>
> Видимо, это стоит реализовать. Нет ли у Вас готовых нароботок уже?

Это реализовано в mageia, оттуда можно взять готовое решение.
Provides вида pythonegg(2)(distro)  в python2-distro

Но похоже намечается новый стандарт -
В федоре и магее появились очень интересные provides вида
python2/3dist(...) с приведенным именем модуля в pypi.
python2dist(aaargh)   python2-aaargh
python2dist(abclient) python2-abclient
python3dist(achoo)    python3-achoo

---------

imz@: Ввод нового вида Provides/Requires будет немного 
болезненнным/потербует некоторого времени для ввода: прежде, чем 
использовать Requires, нужно сгенерировать Provides в других пакетах. 
(Вариант отображть имя egginfo-файла в имя пакета по таблице мне кажется 
не очень честным: пр перетасовке файлов или переименовании пакетов старые 
Requires будут недействительными. Хотя сейчас это так делается для 
некоторых видов зависимостей -- по contents_index; но это мн етоже кажется 
неидеальным.)

Подумал ещё о варианте превращать это в файловые зависимости, но такое 
простое решение сработает плохо, потому что egginfo-файлы могут лежать в 
разных директориях у нас (по крайней мере: внтури /usr/lib или 
/usr/lib64). Может быть, унификация и возможна, но это такой же 
необходимый первый этап, как и генерация Provides в первом варианте.

-- 
Best regards,
Ivan