[devel] Python Modules Policy:

Чт Фев 12 13:03:01 MSK 2004

On Thu, Feb 12, 2004 at 11:29:59AM +0300, Алексей Любимов wrote:
> >Нет. Их можно будет собирать "неодновременно", т.е. в два прохода.
> >Может быть, даже автоматом.
> >
> А, так это в том смысле, что из одного спека за один проход собирать 
> пакеты для всех питонов трудоемко?
> Это как раз само собой разумеется.
> 
> Раз так, то на зоп в сизифе и все, что посложнее "hello world" можно (и 
> нужно) не забивать :)
См. письмо про RFC.
Андрей Орлов в джаббере высказал мнение, что, возможно, стоит пойти по
другому пути, с доводкой до ума libAltDist. Возможно, это тоже путь.
Более подробно он выскажется сам.

Сейчас, я так понимаю, нужно выслушать мнение тех, кто реально будет эти
самые модуля собирать (и использовать).

> >ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям,
> >но автоматизируется. Прокомментируйте его, пожалуйста.
> Менять макросы rpmbuild?
> По моему это источник еще одной головной боли.
> Опять будет куча unmets, как это происходит при любом чихе сейчас с 
> перлом и прочими.
См. моё решение. F*cking magic, но таки "работает для меня". Причем,
если нужно, добавки происходят относительно безболезненно, как _мне_
_кажется_ в _настоящее время_

> Но самое главное, будет непрозрачное повдение rpm при сборке пакета.
> Проблема с с зависимостями питона не так серьезна, чтобы рубить с плеча.
> По моему все очень просто - поставил Requires: python = %<pversion> и 
> получил нужную зависимость.
Все автоматом происходит. Аллилуйя! :-)

> А не поставил - получил более свободный и универсальный вариант. Всем 
> хорошо и никому плохо.
Но для модулей такая зависимость реально нужна.

> >>>Предлагается подумать над следующими двумя полиси:
> >>>6. Программы на python, не зависящие от конкретной версии питона
> >>>(epydoc, python-doc-tools), собираются _без_ байткода и,
> >>>соответственно, без привязки к точной версии питона, используется
> >>>#!/usr/bin/env python ...
> >>>     
> >>>
> >>А где же они лежать будут? по логике все равно в 
> >>python?.?/site-packages/
> >>   
> >>
> >Нет. Питоньи скрипты (н-р, python-doc-tools) лежат не там.
> >epydoc тоже лежит не там, вроде бы. Если нужно подумать над
> >"версионно-независимом" каталоге для питона, его можно организовать,
> >насколько я понимаю.
> Ну так это же просто программы на питоне.
> Однако все равно любая такая прога сложнее трех строк  зависит от  
> импортируемых модулей из python?.?/site-packages/.
Да, конечно. Но они как правило говорят просто

import smth

а уж откуда этот smth потянется - забота того питона, при помощи
которого эта прога выполняется. Сменится питон, сменится и место.
Но это никак не заденет саму прогу (вопросы совместимости разных
версий _языка_ оставим в стороне)

> репорте gdesklets22, а не gdesklets? Да и класть только 
> некомпилированные модули в пакет, это фактически ухудшить качество 
> пакета. Скомпилировать его юзер уже не сможет и ему будет выгоднее 
> просто скопировать содержимое  к себе в хоум и запускать оттуда. На этот 
> слакварный вариант целимся?
Нет, Алексей, я, видимо, плохо объяснил свою точку зрения. Смотрите, как
это вижу себе я:

	* имеется Twisted (благо, он действительно имеется, собран и
	  подходит для примера)
	* при сборке образуются следующие модули:
		* python<NN>-Twisted - сборище _модулей_ из Twisted
		  (вероятно, я распилю этот пакет на Twisted,
		  Twisted-web, Twisted-gtk итп)
		* python-Twisted-utils - вещи, которые, грубо говоря,
		  идут в /usr/bin/ и от конкретной версии питон не
		  зависят
		* python-Twisted-doc и всё остальное прочее барахло,
		  которое потребно лишь девелоперам

> >Без разможения пакетов - плохо, по-моему. Я сейчас периодически сам
> >заглядываю в твистедовые потроха, чтобы понять, что же имелось ввиду в
> >доке.
> я имею в виду не молчаливое удаление *.py как это сделали с *.la, а 
> некий инструмент, селектирующий систему после (и в процессе) установки.
Ну, можно, конечно, оформить это как %def_without python_source,
но, гхм... В общем, думать надо.

> А под размножением пакетов я имею в виду следующее:
> что у нас сегодня есть из _одного_ пакета/дистрибутива Zope
> 
> Zope-DateTime - Date and time representation
...
> Zope-reStructuredText - reStructuredText - enhanced automatic text markup
> 
> То есть один дистрибутив расщепился на 15 пакетов, что уже много.
В общем, пилить его надо. Не знаю, какова ситуация именно с Zope, но
по зависимостям полный Twisted, если его паковать правильно, тянет,
н-р, pygtk, который тянет GTK+/Glade, а что начинается дальше, в общем,
рассказывать не надо, да? :-) И это несмотря на то, что я, в общем,
захотел безобидной вещи, простенький серверок поверх http запустить :-)
"Абидна, да-а?! Ничего нэ сдэлал, да-а?!"

Так что, бить на подпакеты нужно. Другое дело, что сорцы вполне могут
ехать в одном большом пакете, который "требует всего". Девелоперу можно
и иксу поставить, гигабайты нынче дешевы.

Кстати, насчет .pyc vs .pyo. В .pyc есть какой-нибудь смысл при наличии
.pyo (кроме отдельно оговоренных единичных случаев)?

> Замечу, что зоп, это здорово, но еще далеко не все.
Угу. 
> 
> Вот, что дополнительно используется только на www.linux-os.ru (ничего 
> такого специфичного)
> 
> ArchExample
...
Супер.

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

twisted -ny server_start.py (или вообще .tap)

При этом версия питона "по умолчанию" мне, в общем, по барабану
(ну, при условии, что у меня код написан так, что его реально можно
таскать. Если таскать нельзя, то в том месте, которое таскать нельзя
стоит: "нужен именно pythonX.Y!" и старт обламывается). При этом мне не
нужно ни альтернатив (которые, вообще-то, не самостоятельные в данном
случае, а slave'ы на python), ничего специального. Выбор версии питона
происходит в момент пробегания по /usr/bin/python -> ... ->
/usr/bin/pythonX.Y

> >У Андрея были практические соображения, почему в боевую версию НЕ надо
> >пихать сорцы. С другой стороны, мой небольшой практический опыт
> >показывает, что сорцы _иногда_ нужны.
> мой опыт говорит, что сырцы нужны всегда или почти всегда.
> вот сейчас пытаюсь завести науменовскую crm 2.3 без сырцов и ни хрена не 
> получается.
> версия 2.2 с сырцами завелась практически сразу, потому как из них было 
> видно, что конкретно не устраивает программу.
Удачи :-))

> >Это никак не упихивается в рамки distutils?
> /usr/lib/python2.3/site-packages/libaltdist.py ?
> не похоже.
> Эта штука должна по идее сопровождать установленную систему все время 
> его существования (как апт или control) и даже иметь страничку в 
> конфигураторе (которого нет).
> Вобщем пока все слишком непонятно, чтобы обсуждать рамки.
Ну, когда-то надо начинать.

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20040212/5f8c85c8/attachment-0001.bin>