Re: [devel] Python Modules Policy:

[Alexey Morozov <alex-altlinux@idisys.iae.nsk.su>]

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

On Thu, Feb 12, 2004 at 08:10:53PM +0300, Алексей Любимов wrote:
> >Нет, Вы все-таки попробуйте :-)
> ближе к выходным попробую.
Ok.

> >Ну, "программа", в общем случае, ни под что не собрана, она сама по себе
> >программа. С #!/usr/bin/env python .. внутри. Как сделать так, чтобы
> >она хотела python-Module1 python-Module2 python-Module3, и при установку
> >в систему _еще_ одного питона, в _дополнение_ к существующему, автоматом
> >притаскивались pythonXY-Module1, pythonXY-Module2 итп, я [пока] не знаю.
> так вот о том и речь.
> с этой ерунды же все и началось, что при наличии нескольких питонов, (а 
> это норма, учитывая необходимость пересборки всех модулей перед 
> снесением старой версии)  зависимости получаются левыми...
Нет. Модули должны иметь зависимость на pythonXY-RequiredModule.
Соответственно дерево модулей строится отдельно для каждого
питона. С программами - да, с ними хуже. С другой стороны, установка
двух питонов - это, все же, и правда для нуждающихся. А там и ручками не
грех подумать.

> >Ну, надо что-то придумывать. Либо сказать, что те, кто держит у себя на
> >машине сразу _два_ питона, должны делать всё руками и внимательно.
> >Разница лишь в том, что предложенная мной схема _допускает_ возможность
> >решения в случае, если питонов больше одного. Но на уровне: "надо -
> >сделай сам". Хоть и предоставляет достаточно удобные [на мой взгляд ;-)]
> >ручки конечному пользователю.
> да пока что "ручки" Орлова ничем не хуже. Что там, что там есть 
> требование держать только один питон.
> Чего тогда колготится?
Очень просто. Я этот вопрос уже задавал Андрею: в какой момент сносить
[старый] питон? В момент, когда он соберет новый? Я (точнее, Вы)
останетесь без Зопы (хе-хе, Поручик в восторге). Когда Андрей дособирает
Зопу? Это довольно длинный процесс, к тому же не факт, что то, что нужно
Вам он тоже переберет. Поэтому возникает два питона. На каком из них
ездить, в общем решает каждый конкретный пользователь сизифа. Мне вот
например, совершенно нет резону дожидаться, пока Андрей закончит свои
Зоповые разборки, я могу смело двинуть альтернативу на питонX.{Y+1} и
начать перебирать требуемые мне модуля. А кому-то без Зопы не жизнь,
и его все эти появляющиеся в репозитории модули под новый модный питон
совершенно не греют. Хуже того, если возникает где-то проблема, скажем,
с безопасностью, то человек _вынужден_ устраивать свой собственный
зоопарк модулей, потому что python-Module-%версия-%{релиз_с_фиксом} уже
собран для нового питона и для старого его придется перебирать
самостоятельно, а потом ВЕШАТЬ ПАКЕТ НА ХОЛД, чтобы не дай Бог, не
обновилось ненароком. Вот этих проблем я и пытаюсь избежать, придумывая
свой велосипед.

> >>+ Альтернатива slave к питону.
> >>   
> >>
> >Альтернатива на _что_?
> на twisted. но это не обязательно, если поставить conficts друг на друга.
Не надо conflicts. Собирать модули для новых версий станет ПРОСТО
НЕВОЗМОЖНО. Смотрите:

Twisted зависит от вагона и маленькой тележки других модулей. Чтобы
собрать пакет под новый питон надо (теоретически, по крайней мере),
поставить всё, от чего он зависит (хотя бы, для того, чтобы проверить
его фактическую работоспособность). Если мы ставим pyserial, собранный
для 2.3, и он при этом конфликтует с pyserial'ом, который под 2.2, то
pyserial под 2.2 сносится, заодно унося за собой весь твистед под 2.2.
Оба-на. Тут и правда становится очень жарко, все девелоперы, которые
так или иначе пользуются моей машиной, остаются без средств разработки,
и им ничего не остается, как начинать помогать мне собирать модули,
требуемые для твистеда под 2.3. Тыкскыть, не расслабляцца! Постановка
людей в экстремальные условия, как верно заметил Райдер в треде про
полиси, приводит к резкому увеличению производительности труда. Я, как
ПМ должен быть просто в восторге от такого :-). Но только вот, как бы
это... жестковато, добрее надо к людЯм относиться :-)

> Я бы просто клал *.py в пакет *.doc в /usr/share/doc/src/путь от 
> корня/*.py
> Захотел исходничков - поставил *.doc и посмотрел.
Вариант. 2All: Еще будут мнения?

> Хотя в общем случае - не дело rpm такие слои нарезать. Дело рпм ставить 
> пакеты и следить за минимумом зависимостей. И все...
Уж, что есть...

> >Меня список впечатлил. Как говорится, и шо ви с этог'о имеете? :-)
> половина, это зависимости plone + рассылка postboxer + форум cmfboard с 
> зависимостями + клиент для imap почты + wiki.
> И это все...
Понятно.

> >Ну, это да, конечно. Просто если держать обе сразу (у меня были такие
> >шальные мысли, по крайней мере, поначалу), то тогда их (программы)
> >приходится разводить по именам, городить альтернативы итп. А зачем,
> >если они все равно одинаковые? Поэтому я и поступил таким вот образом.
> да конечно проще просто  поставить конфликт друг на друга. в 99% это 
> будет самое умное решение.
См. выше про конфликт.


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