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

[Stanislav Levin <slev@altlinux.org>]

[-- 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 --]