As of setuptools 75.8.1: https://setuptools.pypa.io/en/stable/history.html#v75-8-1 > Fix wheel file naming to follow binary distribution specification – by @di (#4766) Today's spec: https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-contents Previously setuptools didn't follow the spec and maintainers couldn't use %pyproject_distinfo macro which normalizes names according to the specification. https://www.altlinux.org/Python_packaging_guide#Metadata Test rebuild of packages with the aforementioned version of setuptools leads to 241 new errors.
One of the possible options to handle this: - add compat macro for setuptools-generated dist-info. It's either standard normalization (modern) or setuptools' one (legacy). The default can be switched depending on a branch (set by rpm-build-python3). - pros: - this allows to seamlessly copy packages between branches - cons: - need to maintain the macro and backport rpm-build-python3 to supported branches - need to take care of the default on setuptools backport
Я уже говорил, что макрос про dist-info совсем неудачный оказался и в своих пакетах я его использую только если если забываю убрать после автогенерации спека. Предлагаю не городить безумное количество макросов и общаться на языке большинства пользователей и участников тим.
(In reply to Grigory Ustinov from comment #2) > Я уже говорил, что макрос про dist-info совсем неудачный оказался и в своих > пакетах я его использую только если если забываю убрать после автогенерации > спека. Имя директории *.dist-info стандартизировано и все сборочные бэкенды следуют этому стандарту, все кроме setuptools < 75.8.1 (так исторически сложилось). То есть имя сгенерированной директорий фактически собранного проекта должно совпадать (читать как assert) с ожидаемым %pyproject_distinfo. Сейчас в случае с setuptools и проектами, имя которых не нормализуется согласно стандарту, имя dist-info жестко прибито гвоздями или "просто" заглобленно с "*". Например, https://git.altlinux.org/gears/p/python3-module-zope.testrunner.git?p=python3-module-zope.testrunner.git;a=blob;f=.gear/zope.testrunner.spec;h=9714735fac8efa8174c5277e49e470fffcb86b0b;hb=f5ed172e958bbb6f238a68f96ad2477fe2f55709#l64 > %define pypi_name zope.testrunner > %python3_sitelibdir/%pypi_name-%version.dist-info/ С setuptools >= 75.8.1, это ожидание будет сломано, потому что имя dist-info будет нормализовано согласно стандарту. В примере с zope.testrunner это zope_testrunner-7.0.dist-info (. заменено на _). То есть проблема не в использовании %pyproject_distinfo, а проблема в отсутствии соответствующего макроса для setuptools и его неиспользовании, что и привело к ручному заданию ожиданий. Сейчас можно было бы переключить нормализацию на стандартный вариант и не пришлось бы править какую-то часть из 241 спеков. Но имеем, что имеем, теперь придется поправить эти спеки, вопрос как именно. 1) меняем *.dist-info на %pyproject_distinfo и забываем про особенности setuptools ... пока такие пакеты не понадобится скопировать в бранчи с setuptools < 75.8.1, бэкпорт которого реалистичен для p11 и потребует значительных усилий для всего остального. 2) делаем макрос для совместимости между бранчами с возможностью переключения реализации (sisyphus - standard, p11 - setuptools, p10 - setuptools, etc.). Меняем *.dist-info на %pyproject_distinfo_setuptools_compat (просто например!), бэкпортим rpm-build-python3. Пакеты можно копировать. Это более сложный вариант.
(Ответ для Stanislav Levin на комментарий #3) > С setuptools >= 75.8.1, это ожидание будет сломано, потому что имя dist-info > будет нормализовано согласно стандарту. В примере с zope.testrunner > это zope_testrunner-7.0.dist-info (. заменено на _). > > То есть проблема не в использовании %pyproject_distinfo, а проблема в > отсутствии соответствующего макроса для setuptools и его неиспользовании, > что и привело к ручному заданию ожиданий. Сейчас можно было бы переключить > нормализацию на стандартный вариант и не пришлось бы править какую-то часть > из 241 спеков. Но имеем, что имеем, теперь придется поправить эти спеки, > вопрос как именно. Написать скрипт, который в автоматическом или полуавтоматическом режиме всё поправит. Если у вас на это не хватает квалификации, позвольте это сделать мне.
