[devel] Модули python3

[devel] Модули python3

[Aleksei Nikiforov]

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

Я пытаюсь разобраться с обновлением 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.

С уважением,
Алексей Никифоров

Re: [devel] Модули python3

[Ivan Zakharyaschev]

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

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 невозможно написать.

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

Теоретически, конечно, всякие варианты возможно, но у нас сейчас такой 
выбран. Вероятно, в Debian по-другому. В Сизифе тоже были предусмотрены 
такие механизмы для размножения модулей, остались атавизмы в виде всяких 
%python_setup_module, которые сейчас не очень полезны. (И этого уже нет 
для Python 3.)

-- 
Best regards,
Ivan

Re: [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
> 

Re: [devel] Модули python3

[Ivan Zakharyaschev]

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

Hello!

On Wed, 28 Mar 2018, Aleksei Nikiforov wrote:

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

Да, в принципе можно так. Такой подход даже не будет мешать старому: можно 
постепенно собирать новые модули с новым форматом Requires+Provides и они 
не будут мешать старому питону.

>>  Во-вторых, технически это тогда должно было бы реализовываться по-другому.
>>  Если 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'.

Как-то неестественно иметь один файл, но два Requires -- для python3.5 и 
python3.6. По смыслу это скорее ИЛИ, а не И. Тогда уж лучше разделять на 
две копии, больше гибкости при установке.

Было бы удобнее собирать варианты, если бы пакеты уже перешли на сборку 
вариантов с помощью specsubst (а не дублированием похожих команд в одном 
спеке). Пример: python{,3}-module-enchant. girar-nmu только плохо умеет 
такую схему, но можно же доделать и сделать girar-nmu лучше. (У меня ещё 
мои скрипты похожего назначения, их я сразу писал с мыслью о specsubst, но 
без мысли об srpm.)

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

Последняя история, да, что между 200 и 300 было:

https://lists.altlinux.org/pipermail/sisyphus-incominger/2016-April/433058.html
http://git.altlinux.org/tasks/archive/done/_155/159698/logs/events.49.2.log

> маловероятное событие. Даже если попросить ничего не обновлять в репозитории,

Да питон-модули в основном всё равно никто годами не обновляет, за 
исключением массовых набегов роботов и не совсем.

> есть немаленькая вероятность, что с первого раза такое огромное задание не 
> пройдёт всё равно. Куча более мелких заданий для постепенной сборки модулей 
> питона для новой версии лишено этого весомого на мой взгляд недостатка.

Это не очень страшно, по-моему, что не с первого раза. Даже если кто-то 
один какой-то пакет обновит, то совсем несложно его пересборку добавить в 
задание.

Я тогда использовал girar-nmu. (Для следующей массовой задаче по 
переписыванию спеков и сборке сделал свои скрипты, которые мне были более 
удобны, но их в виде пакета не опубликовал. Они больше для работы только с 
gear.)

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

Лично мне было бы проще ещё раз по последней схеме обновить, потому что 
трудности на этом пути уже проходил и проще вспомнить и понять, что 
происходит. Не хотелось бы делать это самому, хотелось делиться этим 
опытом с новыми людьми.

Ещё тут такое свойство могу отметить: желание иметь полный набор модулей 
для нового python3 тут просто превращается в требование по отсутствию 
unmet-ов, проверяемое сборочницей. Т.е. не так, что человек держит в 
голове или в своих записках, что ещё стоит собрать, а эта информация 
вычисляется и одинаково на виду у всех мейнтейнеров.

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

Re: [devel] Модули python3

[Igor Vlasenko]

On Wed, Mar 28, 2018 at 12:06:54PM +0300, Ivan Zakharyaschev wrote:
> Было бы удобнее собирать варианты, если бы пакеты уже перешли на сборку
> вариантов с помощью specsubst (а не дублированием похожих команд в одном
> спеке). Пример: python{,3}-module-enchant. girar-nmu только плохо умеет
> такую схему, но можно же доделать и сделать girar-nmu лучше. (У меня ещё мои
> скрипты похожего назначения, их я сразу писал с мыслью о specsubst, но без
> мысли об srpm.)

girar-nmu расширяемый, там опцией --hook можно грузить
пользовательские скрипты редактирования.
с ними теоретически можно сделать все, что угодно.
Всегда обращайтесь --- достаточно поставить задачу.


-- 

I V