[devel] Модули python3

[Aleksei Nikiforov]

Здравствуйте.

27.03.2018 20:30, Ivan Zakharyaschev пишет:
> Hello!
> 
> On Tue, 27 Mar 2018, Aleksei Nikiforov wrote:
> 
>> Я пытаюсь разобраться с обновлением python3 до версии 3.6.x и возник 
>> вопрос: почему архитектурно-зависимые модули python3 в основном лежат 
>> в % _libdir/python3 вместо %_libdir/python3.5? Если бы модули лежали в 
>> % _libdir/python3.5, то рядом в %_libdir/python3.6 можно было бы 
>> положить модули для python-3.6.x, а в будущем и для 3.7.x, а сейчас 
>> обновление python-3 невозможно без одномоментной пересборки всего 
>> содержимого %_libdir/python3 c новой версией python3.
> 
> Не совсем так. Только бинарных модулей.
> 

Да, действительно.

> Во-первых, из-за стремления к политике поддерживать только один вариант 
> в Сизифе. С этим все согласились и при последней пересборке с python 3.5.
> 

Временная сборка модулей питона для нескольких версий питона при 
апгрейде до новой версии питона не является поддержкой нескольких версий 
питона. Это скорее удобство для обновления, временная мера при 
обновлении, а не постоянное состояние репозитория :). В текущей сборке 
обновление неудобно делать: сейчас нужно всё обновлять одним огромным 
заданием, а сборку модулей под несколько версий можно делать постепенно.

> Во-вторых, технически это тогда должно было бы реализовываться 
> по-другому. Если noarch-пакеты общие, как сейчас, т.е. подходят для 
> использования любой версией python3, то механизм Requires+Provides в rpm 
> не позволяет выразить нужные условия работоспособности. Например:
> 
> модуль a импортирует noarch-модуль b, b импортирует c.
> 
> a и с -- бинарные.
> 
> Тогда когда импортируется a для python 3.6, должен импортироваться b, а 
> потом c для python 3.6 тоже. И так же для python 3.5. Соответсвующий 
> Requires в пакете с модулем b невозможно написать.
> 
> Раз так не получается, остаётся только сборка каждого модуля для каждой 
> версии питона, т.е. все-все-все модули в Сизифе надо будет собрать ещё 
> раз. Ну и этого может не хотеться, например, потому что слишком долгий 
> процесс, если делать вручную.

Это единственный минус такого подхода, который я сейчас вижу: noarch 
пакеты тоже придётся пересобирать (ради обновления requires+provides).
Но сделать так, чтобы был только один noarch пакет модулей, а не по 
одному на каждую версию питона, вполне можно. Содержимое noarch модулей 
может также лежать в %_libexecdir/python3 для всех версий, просто 
provides+requires обновится.

Сначала собираем новый python (3.6), затем мы собираем постепенно все 
модули и для python 3.5, и для 3.6. Раз зависимости идут 'a -> b 
(noarch) -> c', то сначала надо собирать 'c'. Если попытаться собрать 
'a', то в репозиторий сборка не пройдёт из-за недостатка зависимостей: 
'b' предоставляет только зависимости для python 3.5, но не для python 
3.6 - пакет 'b' ещё не был пересобран, а пакет 'a' уже потребует 
зависимости и для 3.5, и для 3.6 после пересборки. Пакет 'b' тоже нельзя 
пересобрать из-за той же проблемы: у пакета 'c' нет Provides для python 
3.6, есть только для python 3.5.
Таким образом пересобирается пакет 'c' (предварительно, допустим, все 
его зависимости пересобрали) для python 3.5 и 3.6, у него появились 
Provides для этих двух версий, и теперь можно пересобрать пакет 'b', а 
затем - 'a'.
А когда все пакеты будут собраны и с python 3.5, и с 3.6, работа пойдёт 
в обратном направлении - постепенно пересобрать все пакеты без python 3.5.

Это, конечно, много пересборок пакетов, и работа по первоначальной 
поддержке другой схемы сборки модулей, но и текущее состояние не лишено 
минусов: задача обновления тоже огромная, её и подготовка и выполнение 
занимают немало времени, и должна эта задача за один заход завершиться 
успешно, что, учитывая размер такого задания, а у меня сейчас получается 
под 300 пакетов, довольно маловероятное событие. Даже если попросить 
ничего не обновлять в репозитории, есть немаленькая вероятность, что с 
первого раза такое огромное задание не пройдёт всё равно. Куча более 
мелких заданий для постепенной сборки модулей питона для новой версии 
лишено этого весомого на мой взгляд недостатка.

В итоге, сейчас обновление python3 - тоже небыстрый процесс. Возможно, 
пересборка всех модулей и дольше, но она возможна небольшими заданиями 
по несколько пакетов за раз, что позволяет выполнять эту работу 
параллельно с остальными изменениями в репозитории, т.е. 
обновлениями/удалениями/добавлениями других пакетов, которые как-либо 
взаимодействуют с python3. С текущим подходом к обновлению python3 
параллельная работа с репозиторием значительно снижает вероятность 
успеха такого обновления, соответственно увеличивая время этого обновления.

> 
> Теоретически, конечно, всякие варианты возможно, но у нас сейчас такой 
> выбран. Вероятно, в Debian по-другому. В Сизифе тоже были предусмотрены 
> такие механизмы для размножения модулей, остались атавизмы в виде всяких 
> %python_setup_module, которые сейчас не очень полезны. (И этого уже нет 
> для Python 3.)
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>