[devel] Спасём python3 вместе!

[devel] Спасём python3 вместе!

[Grigory Ustinov]

Добрый день, уважаемые участники ALT Linux Team.

Прошло уже почти два года с момента опубликования статьи:

https://www.altlinux.org/Management_of_Python_dependencies_sources

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

Эмоции в сторону, давайте сосредоточимся на проблемах этого подхода:

1.) Данный подход полностью ломает идею спек-файла, который по 
оригинальной задумке должен хранить _всю_ информацию о пакете. То есть 
открыв спек-файл нельзя определить его зависимости, в поиске по спекам 
нельзя отгрепать зависимости и так далее.

2.) Спек превращается в результат автогенерации бесчисленного количества 
макросов. Раньше подобным автогенератам было место в репозитории 
Autoimports, в сизиф же пропускались "очеловеченные" спеки, которые 
доступны для чтения и понимания участникам сообщества. Перефразируя 
Мартина Фаулера "Скрипты могут писать спеки, понятные сборочнице, 
хорошие мейнтейнеры пишут спеки понятные людям".

3.) Проблемы с бэкпортами. Вспоминаем сколько спотыкались о другую 
"инновационную разработку" под названием ubt.

4.) Автоматическая генерация зависимостей очевидно порождает мусор. 
Поэтому в 180 пакетах из 560 присутствуют костыли под названием 
*_filter, которые призваны отфильтровывать список зависимостей. То есть 
вместо списка зависимостей, в спеке идёт список _независимостей_.
Вот как это выглядит: 
https://packages.altlinux.org/ru/sisyphus/srpms/python3-module-isort/specfiles/

Как минимум 75 пакетов собранных с этими автоматическими зависимостями 
этого механизма абсолютно не требуют, поскольку нуждаются всего в 3 
пакетах setuptools, wheel и pytest.

5.) В текущем состоянии наш замечательный репозиторий сизифа потерял 
консистентность в области питоновских пакетов. Очевидно, что для 
обновления или исправления одних пакетов зачастую приходится влезать в 
другие. Далеко не у всех есть желание разбираться в модулях собранных 
этим необычным способом. Так, например, за последний год было 
_испорчено_ несколько ключевых модулей, для бутстрапа нового питона. 
Ручки бутстрапа оторваны, списки зависимостей переделаны в 
автоматическом режиме, хотя раньше всё было чётко выверено.


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

Автору данного подхода рекомендую доделать свою автоматику таким 
образом, чтобы ей можно было пользоваться добровольно. То есть написать 
скрипт таким образом, чтобы он из существующих файлов со спецификациями 
зависимостей выдирал всё необходимое как сейчас, но добавлял их не в 
отдельный json-файл а в привычном для всех виде как BuildRequires в 
спек-файле. Я такое уже реализовывал для обновления библиотек openstack.

Re: [devel] Спасём python3 вместе!

[Anton Farygin]

On 12.02.2025 19:54, Grigory Ustinov wrote:
>
>
> Я предлагаю всем заинтересованным против принятия этой технологии 
> лицам высказаться в этом треде. Со своей стороны могу предложить 
> помощь в устранении последствий этого "эксперимента". 75 пакетов 
> чинятся элементарным скриптом, для других готов попробовать придумать 
> скрипт посложнее. 

Я как, в данном случае, нейтральное лицо могу сказать что подобный 
подход _придётся_ переносить ещё и на ocaml.

Почему ? Всё очень просто - мы должны научиться собирать так же, как это 
делает апстрим. В моём (с ocaml) случае вместо pypi есть репозиторий 
opam и в для каждого пакета есть свои файлы спецификации, содержащие 
требуемые зависимости для сборки.

Я неспешно иду к тому, что список Requires для каждого ocaml пакета 
будет вычисляться автоматически, но начать мне придётся с того, что бы 
каждый devel пакет ocaml провайдил что-то с именем, однозначно 
определяляющим уникальное имя этого пакета в репозитории opam.

Поэтому я с интересом наблюдаю за попыткой реализации подобного подхода 
в PYTHON и могу сказать что в моих пакетах, в которых используется такой 
подход - я озвученных в письме проблем не заметил.

Что касается вынесения чего-либо из specfile в отдельный файл - то 
понятно, что таким списком сильно проще управлять, а RPM specfile 
предлагает для простой реализации механизм Include, которым даже 
некоторые ментейнеры иногда пользуются:

d/dqt5-base/qtbase.spec:%include %SOURCE1
d/dqt5-declarative/qtdeclarative.spec:%include %SOURCE1
d/dqt5-declarative/qtdeclarative.spec:%include %SOURCE2
d/dqt6-base/qtbase.spec:%include %SOURCE1
d/dqt6-declarative/qtdeclarative.spec:%include %SOURCE1
d/dqt6-declarative/qtdeclarative.spec:%include %SOURCE2
q/qt5-base/qtbase.spec:%include %SOURCE1
q/qt5-declarative/qtdeclarative.spec:%include %SOURCE1
q/qt5-declarative/qtdeclarative.spec:%include %SOURCE2
q/qt6-base/qtbase.spec:%include %SOURCE1
q/qt6-declarative/qtdeclarative.spec:%include %SOURCE1
q/qt6-declarative/qtdeclarative.spec:%include %SOURCE2
r/rpm-build-rpm-eval/rpm-build-rpm-eval.spec:%include %SOURCE2
s/ssh-provider-gostcrypto/ssh-provider.spec:%include %SOURCE0
s/ssh-provider-openquantumsafe/ssh-provider.spec:%include %SOURCE0
s/ssh-provider-openssh/ssh-provider.spec:%include %SOURCE0
w/webserver-common/webserver-common.spec:%include %SOURCE2

Re: [devel] Спасём python3 вместе!

[Anton Farygin]

On 13.02.2025 07:30, Anton Farygin wrote:
>
> Я неспешно иду к тому, что список Requires для каждого ocaml пакета 
> будет вычисляться автоматически, но начать мне придётся с того, что бы 
> каждый devel пакет ocaml провайдил что-то с именем, однозначно 
> определяляющим уникальное имя этого пакета в репозитории opam.
Здесь читать BuldRequires, естественно. Обычные Requires и Provides уже 
вычисляются автоматически.

Re: [devel] Спасём python3 вместе!

[Grigory Ustinov]

13.02.2025 7:30, Anton Farygin пишет:
> On 12.02.2025 19:54, Grigory Ustinov wrote:
>>
>>
>> Я предлагаю всем заинтересованным против принятия этой технологии 
>> лицам высказаться в этом треде. Со своей стороны могу предложить 
>> помощь в устранении последствий этого "эксперимента". 75 пакетов 
>> чинятся элементарным скриптом, для других готов попробовать придумать 
>> скрипт посложнее. 
>
> Я как, в данном случае, нейтральное лицо могу сказать что подобный 
> подход _придётся_ переносить ещё и на ocaml.
>
> Почему ? Всё очень просто - мы должны научиться собирать так же, как 
> это делает апстрим. В моём (с ocaml) случае вместо pypi есть 
> репозиторий opam и в для каждого пакета есть свои файлы спецификации, 
> содержащие требуемые зависимости для сборки.
Надо понимать специфику репозиториев для модулей разных ЯП. Есть к 
примеру перл и хаскель, где действуют строгие правила в отношении 
зависимостей. Питон же этим похвастаться не может. Некоторые апстримы 
вообще не ставят тэги на гитхабе, а многие периодически забывают поднять 
версию. И в списки зависимостей по ощущениям можно писать вообще что 
угодно. То есть стандарт выпустили, а обеспечение его выполнения лежит 
на совести апстримов.
> Я неспешно иду к тому, что список Requires для каждого ocaml пакета 
> будет вычисляться автоматически, но начать мне придётся с того, что бы 
> каждый devel пакет ocaml провайдил что-то с именем, однозначно 
> определяляющим уникальное имя этого пакета в репозитории opam.
>
> Поэтому я с интересом наблюдаю за попыткой реализации подобного 
> подхода в PYTHON и могу сказать что в моих пакетах, в которых 
> используется такой подход - я озвученных в письме проблем не заметил.
>
> Что касается вынесения чего-либо из specfile в отдельный файл - то 
> понятно, что таким списком сильно проще управлять, а RPM specfile 
> предлагает для простой реализации механизм Include, которым даже 
> некоторые ментейнеры иногда пользуются:
Это очень маленький список исключений.
>
> d/dqt5-base/qtbase.spec:%include %SOURCE1
> d/dqt5-declarative/qtdeclarative.spec:%include %SOURCE1
> d/dqt5-declarative/qtdeclarative.spec:%include %SOURCE2
> d/dqt6-base/qtbase.spec:%include %SOURCE1
> d/dqt6-declarative/qtdeclarative.spec:%include %SOURCE1
> d/dqt6-declarative/qtdeclarative.spec:%include %SOURCE2
> q/qt5-base/qtbase.spec:%include %SOURCE1
> q/qt5-declarative/qtdeclarative.spec:%include %SOURCE1
> q/qt5-declarative/qtdeclarative.spec:%include %SOURCE2
> q/qt6-base/qtbase.spec:%include %SOURCE1
> q/qt6-declarative/qtdeclarative.spec:%include %SOURCE1
> q/qt6-declarative/qtdeclarative.spec:%include %SOURCE2
> r/rpm-build-rpm-eval/rpm-build-rpm-eval.spec:%include %SOURCE2
> s/ssh-provider-gostcrypto/ssh-provider.spec:%include %SOURCE0
> s/ssh-provider-openquantumsafe/ssh-provider.spec:%include %SOURCE0
> s/ssh-provider-openssh/ssh-provider.spec:%include %SOURCE0
> w/webserver-common/webserver-common.spec:%include %SOURCE2
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Спасём python3 вместе!

[Ivan A. Melnikov]

On Wed, Feb 12, 2025 at 07:54:49PM +0300, Grigory Ustinov wrote:
> Добрый день, уважаемые участники ALT Linux Team.

[...]

> Эмоции в сторону, давайте сосредоточимся на проблемах этого подхода:
> 
> 1.) Данный подход полностью ломает идею спек-файла, который по оригинальной
> задумке должен хранить _всю_ информацию о пакете. То есть открыв спек-файл
> нельзя определить его зависимости, в поиске по спекам нельзя отгрепать
> зависимости и так далее.

К сожалению, такая идея спек-файла уже давно сломалась сама по себе,
и это можно только принять, отпустить и забыть.

Сборочные зависимости уже давно зависят от такого количества свойств
среды, что могут быть адекватно получены только в специально
сформированном окружении в момет сборки пакета. Какое-то приближение
может быть получено из зависимостей src.rpm (и, соответственно
srclist'ов), но и оно зависимо, например, от архитектуры.

[...]
На пункты 2-4 я думаю ответить отдельным письмом.
[...]

> 5.) В текущем состоянии наш замечательный репозиторий сизифа потерял
> консистентность в области питоновских пакетов. Очевидно, что для обновления
> или исправления одних пакетов зачастую приходится влезать в другие. Далеко
> не у всех есть желание разбираться в модулях собранных этим необычным
> способом. Так, например, за последний год было _испорчено_ несколько
> ключевых модулей, для бутстрапа нового питона. Ручки бутстрапа оторваны,
> списки зависимостей переделаны в автоматическом режиме, хотя раньше всё было
> чётко выверено.

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

-- 
  wbr,
    iv m.

[devel] Вспоминаем ubt (was: Спасём python3 вместе!)

[Sergey V Turchin]

On Wednesday, 12 February 2025 19:54:49 GMT+3 Grigory Ustinov wrote:

[...]
> Вспоминаем сколько спотыкались о другую
> "инновационную разработку" под названием ubt.
Напомните пожалуйста, а то я вижу это только как чьи-то больные фантазии.

[...]

-- 
Regards, Sergey.

Re: [devel] Спасём python3 вместе!

[Stanislav Levin]

[-- Attachment #1.1: Type: text/plain, Size: 9193 bytes --]

Отличный стендап, спасибо.

Давно в девел не было достойного контента :)
Сделаю серьезное лицо, на всякий случай.

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


On 12.02.2025 19:54, Grigory Ustinov wrote:

> 
> 1.) Данный подход полностью ломает идею спек-файла, который по 
> оригинальной задумке должен хранить _всю_ информацию о пакете. То есть 
> открыв спек-файл нельзя определить его зависимости, в поиске по спекам 
> нельзя отгрепать зависимости и так далее.
> 

Это предположение, скорее, больше заблуждение. Почему?

Спек файл - (читай как есть) описание упакечивания того или иного 
проекта, который может быть человекочитаемым, а может и не быть. Может
быть, стоит отключить другие макросы тоже, ведь они скрывают всю 
информацию о пакете? В чем разница?

Результат работы другой автоматики (autoreq, autoprov) никак не 
отображется и не фиксируется в спеке, может быть, стоит запретить их 
тоже? в тихую, без анонсов и обсуждения в списках рассылок ;)

Пока не закидали идеальными тапко-спеками, конечному пользователю 
совершенно неважно, как это мы так странно описываем его любимый проект 
в каком-то там почему-то крайне важном спек файле.

Для определения конечных зависимостей нужно оперировать пакетами, а не 
спекфайлами.

> 2.) Спек превращается в результат автогенерации бесчисленного количества 
> макросов. Раньше подобным автогенератам было место в репозитории 
> Autoimports, в сизиф же пропускались "очеловеченные" спеки, которые 
> доступны для чтения и понимания участникам сообщества. Перефразируя 
> Мартина Фаулера "Скрипты могут писать спеки, понятные сборочнице, 
> хорошие мейнтейнеры пишут спеки понятные людям".

Использование шаблонных спеков с шаблонными макросами упрощает 
упакечивание и дальнейшее сопровождение проектов, это легко 
масштабируемо. Что проще поправить - один макрос или 100500 пакетов?

> 
> 3.) Проблемы с бэкпортами. Вспоминаем сколько спотыкались о другую 
> "инновационную разработку" под названием ubt.

Понимаю, вам максимально скучно, выискивая таинственную группу лиц с 
очень злыми намерениями, ооочень, и ну ооочень таинственную. Но зачем вы 
хотите увидеть зерга зергом? :)

Какие именно проблемы с бэкпортом, ссылки на баги или проблемы нет.

Например,
Есть отличие в бэкэндах, используемых в разных бранчах, которое сейчас 
не позволяет копировать пакеты из сизифа в п11:
https://bugzilla.altlinux.org/show_bug.cgi?id=52903#c3

> 
> 4.) Автоматическая генерация зависимостей очевидно порождает мусор. 
> Поэтому в 180 пакетах из 560 присутствуют костыли под названием 
> *_filter, которые призваны отфильтровывать список зависимостей. То есть 
> вместо списка зависимостей, в спеке идёт список _независимостей_.

вы называете авторов проектов очевидными генераторами мусора ? ;)

Да, как правило, фильтруются неупакованные зависимости, но мы же никогда 
не фильтруем автосгенерированное с autoreq, оно ж идИальное.


> 
> Как минимум 75 пакетов собранных с этими автоматическими зависимостями 
> этого механизма абсолютно не требуют, поскольку нуждаются всего в 3 
> пакетах setuptools, wheel и pytest.

Сегодня, может, и да, а завтра? послезавтра? в других бранчах?
Можно сделать BuildRequires: sisyphus и радоваться, что все тоже собирается.
Или да, давайте, каждый раз массово исправлять спек и пересобирать 
тоннами пакеты, это определенно лучше, почему нет.


> 
> 5.) В текущем состоянии наш замечательный репозиторий сизифа потерял 
> консистентность в области питоновских пакетов. Очевидно, что для 
> обновления или исправления одних пакетов зачастую приходится влезать в 
> другие. Далеко не у всех есть желание разбираться в модулях собранных 
> этим необычным способом. Так, например, за последний год было 
> _испорчено_ несколько ключевых модулей, для бутстрапа нового питона. 
> Ручки бутстрапа оторваны, списки зависимостей переделаны в 
> автоматическом режиме, хотя раньше всё было чётко выверено.

То есть мы теперь получим Python 3.13 не c четко выверенной 84 попытки?

Дело определенно в необычных способах порчи пакетов, гремлинами наверное :)


Немного не воды.

Например, отличия систем поиска зависимостей:
- autoreq ищет абстрактные зависимости. То есть если пакет импортирует 
что-то с определенным именем, то что угодно, предоставляющее это имя, 
удовлетворит эту зависимость
- autoreq не различает Python package и Python module
- metadata - это конкретные зависимости на конкретные проекты, что и 
ожидается upstream-ом
- autoreq не понимает логики разбивки проекта на отдельные компоненты 
или плагины
- metadata умеет работать с extra, делая зависимости опциональными
- autoreq генерирует экстра зависимости на stdlib, мы же ожидаем при 
установке python3 весь его stdlib, не так ли? (привет, 
python3-modules-sqlite3)
- metadata позволяет иметь синхронизированные с апстримом зависимости,
   что колоссально уменьшает нагрузку на сопровождение, по сути, 
перекладывая это на апрстрим (да-да, ожидается, что мейнтейнер - это 
ответственный человек и проверит эти зависимости).


Для интересующихся и неверующих, подобная система, например, 
используется Fedora:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides_and_requirements


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]