[devel] вопрос по сборке python-module

[devel] вопрос по сборке python-module

[Kirill Maslinsky]

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

Добрый день!

Коллеги, кто хорошо разбирается в python policy? ;)

Имеется программа на питоне, собираю в соответствии с инструкциями 
в пакете rpm-build-python (0.21). Автоматический поиск provides
не находит один из модулей, который в мою программу входит, и ставит
его в зависимости. Как правильно с этим бороться: 

%add_python_req_skip pcaudio_zip

или

%py_provides pcaudio_zip

?

Или принципиальной разницы нет? 
Спасибо!

-- 
Kirill Maslinsky
ALT Linux Documentation Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] вопрос по сборке python-module

[Vitaly Lipatov]

On Thursday 31 March 2005 11:22, Kirill Maslinsky wrote:
> поиск provides не находит один из модулей, который в мою
> программу входит, и ставит его в зависимости. Как правильно с
> этим бороться:
>
> %add_python_req_skip pcaudio_zip
Лучше так, чтобы было меньше зависимостей, а то АПТу всё хуже и 
хуже с каждым пакетом.

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] вопрос по сборке python-module

[Andrey Orlov]

On Thursday 31 March 2005 11:22, Kirill Maslinsky wrote:
> Имеется программа на питоне, собираю в соответствии с инструкциями 
> в пакете rpm-build-python (0.21). Автоматический поиск provides
> не находит один из модулей, который в мою программу входит, и ставит
> его в зависимости. Как правильно с этим бороться: 
> 
> %add_python_req_skip pcaudio_zip
> 
> или
> 
> %py_provides pcaudio_zip

Это python faq, а не полиси. Проблема в том, что если автоматический поиск не находит
модуль, то и питон этот модуль, скорее всего, не найдет. Ставить один из выше приведенных
операторов имеет смысл только в том случае, если вы стопудово уверены, что имеете
дело с одним из тех редких случаев, когда это рекомендовано в FAQ. В остальных случаях
стоит поискать проблему в вашем пакете. Типичный случай - модуль импортируется из того
участка кода, который не вызывается при ваших тестах, и этот модуль оттуда действительно недоступен.

Пример:

site-packages/a
site-packages/a/b
site-packages/a/b/test.py (содержит import b)
site-packages/a/b/__init__.py
site-packages/a/__init__.py (содержит import b)

Вот в такой ситуации модуль a полностью работоспособен (т.е. python -c "import a" отрабатывает без ошибок),
но в нем лежит (не откуда не вызываемый) файлик test.py, который __не__ работоспособен, так
как не видит (не может видить), в общем случае, подмодуль b. И именно он порождает спорную зависимость.

Я такие файлы обычно так или иначе удаляю из пакета... . Некоторые другие способы описаны в FAQ.
У вас может быть и другой случай, некоторые из них тоже описаны в FAQ. 

В любом случае, если %add_python_req_skip не нарушает общей логики репозитория (вы вредите только себе), 
то  %py_provides - это точно только для тех, кто точно знает, что делает. Общий ответ такой: если вы размышляете,
стоит ли использовать %py_provides - то это значит, что не стоит. По крайней мере вам.

ЗЫ: Кстати, заявки на разбор полетов таких модулей по прежнему принмаются на python@neural.ru или в багзиллу 
на rpm-build-python. 

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] вопрос по сборке python-module

[Kirill Maslinsky]

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

Привет!

> модуль, то и питон этот модуль, скорее всего, не найдет. Ставить один из выше приведенных
> операторов имеет смысл только в том случае, если вы стопудово уверены, что имеете
> дело с одним из тех редких случаев, когда это рекомендовано в FAQ. В остальных случаях
> стоит поискать проблему в вашем пакете. Типичный случай - модуль импортируется из того
> участка кода, который не вызывается при ваших тестах, и этот модуль оттуда действительно недоступен.
> 
> Пример:
> 
> site-packages/a
> site-packages/a/b
> site-packages/a/b/test.py (содержит import b)
> site-packages/a/b/__init__.py
> site-packages/a/__init__.py (содержит import b)
> 
> Вот в такой ситуации модуль a полностью работоспособен (т.е. python -c "import a" отрабатывает без ошибок),
> но в нем лежит (не откуда не вызываемый) файлик test.py, который __не__ работоспособен, так
> как не видит (не может видить), в общем случае, подмодуль b. И именно он порождает спорную зависимость.

Похоже, у меня не этот случай:

$ fgrep -r audio_zip * 
positron/db/new/__init__.py:import audio_zip
positron/db/new/__init__.py:import pcaudio_zip
positron/db/new/__init__.py:zips = { "audio"      : audio_zip.data,
positron/db/new/__init__.py:         "pcaudio"    : pcaudio_zip.data,
positron/db/new/audio_zip.py:"""Resource audio_zip (from file audio.zip)"""
positron/db/new/pcaudio_zip.py:"""Resource pcaudio_zip (from file pcaudio.zip)"""

При этом provides audio_zip без проблем обнаруживается автоматически, 
а pcaudio_zip -- нет. И вроде бы они употребляются абсолютно симметрично
и даже в соседних строках (выше приведён полный вывод fgrep по 
исходникам программы).

> Я такие файлы обычно так или иначе удаляю из пакета... . Некоторые другие способы описаны в FAQ.
> У вас может быть и другой случай, некоторые из них тоже описаны в FAQ. 
Я как будто бы подходящего случая в FAQ не нашёл. Или есть?

> В любом случае, если %add_python_req_skip не нарушает общей логики репозитория (вы вредите только себе), 
А чем врежу? Что программа сама на найдёт этот модуль? Но у меня работает -- я 
давно ею пользуюсь, просто сейчас решил собрать с 2.4 и выложить в Сизиф.

> то  %py_provides - это точно только для тех, кто точно знает, что делает. Общий ответ такой: если вы размышляете,
> стоит ли использовать %py_provides - то это значит, что не стоит. По крайней мере вам.
> 
> ЗЫ: Кстати, заявки на разбор полетов таких модулей по прежнему принмаются на python@neural.ru или в багзиллу 
> на rpm-build-python. 
Это можно, если имеет смысл (исходя из вышепроцитированного). 
И какая информация нужна, чтобы разобраться -- исходники целиком?

-- 
Kirill Maslinsky
ALT Linux Documentation Team

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] вопрос по сборке python-module

[Andrey Orlov]

On Thursday 31 March 2005 15:52, Kirill Maslinsky wrote:
> Похоже, у меня не этот случай:
> 
> $ fgrep -r audio_zip * 
> positron/db/new/__init__.py:import audio_zip
> positron/db/new/__init__.py:import pcaudio_zip
> positron/db/new/__init__.py:zips = { "audio"      : audio_zip.data,
> positron/db/new/__init__.py:         "pcaudio"    : pcaudio_zip.data,
> positron/db/new/audio_zip.py:"""Resource audio_zip (from file audio.zip)"""
> positron/db/new/pcaudio_zip.py:"""Resource pcaudio_zip (from file pcaudio.zip)"""

Хм. Интересно. На первый взгляд действительно - не этот

> > Я такие файлы обычно так или иначе удаляю из пакета... . Некоторые другие способы описаны в FAQ.
> > У вас может быть и другой случай, некоторые из них тоже описаны в FAQ. 
> Я как будто бы подходящего случая в FAQ не нашёл. Или есть?

:) Будет

> > В любом случае, если %add_python_req_skip не нарушает общей логики репозитория (вы вредите только себе), 
> А чем врежу? Что программа сама на найдёт этот модуль? Но у меня работает -- я 
> давно ею пользуюсь, просто сейчас решил собрать с 2.4 и выложить в Сизиф.

Чем вредите? Тем что кладете потенциально неисправный пакет в сизиф. Такое поведение является ошибкой. Где ошибка - 
в rpm-build-python или у вас в пакете - отдельный вопрос. Но есть значимая вероятность, что у вас. Ошибки нужно искать,
а не прятать голову в песок.

> > ЗЫ: Кстати, заявки на разбор полетов таких модулей по прежнему принмаются на python@neural.ru или в багзиллу 
> > на rpm-build-python. 
> Это можно, если имеет смысл (исходя из вышепроцитированного). 

Имеет.

> И какая информация нужна, чтобы разобраться -- исходники целиком?

src.rpm. Если до 2х метров - можно мылом на python@neural.ru

-- 
WthBstRgrds --
 -- Andrey Orlov --