[devel] Переходное полиси для для питона

[devel] Переходное полиси для для питона

[@ 2007-10-26 17:23 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-26 18:56 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-26 19:24 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-26 21:05 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-26 21:58 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-26 22:45 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-26 23:02 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-26 23:12 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-27 7:58 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-27 14:49 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-27 16:15 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-27 6:22 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-27 8:05 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-30 8:30 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 0:56 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 1:58 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 4:10 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 7:38 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 9:00 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 9:41 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 13:49 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 10:27 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 22:52 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 10:08 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 10:31 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 11:25 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 14:12 UTC (permalink / raw)]

Re: [devel] Переходное полиси для для питона

[@ 2007-10-28 16:52 UTC (permalink / raw)]

[devel] python vs gcc

[@ 2007-10-28 17:34 UTC (permalink / raw)]

Re: [devel] python vs gcc

[Peter V. Saveliev]

В сообщении от Sunday 28 October 2007 20:34:10 Alexey Tourbin написал(а):
> On Sun, Oct 28, 2007 at 08:52:39PM +0400, Peter V. Saveliev wrote:
> > (исключая gcc -- там полный набор), лишая разработчика универсальности
> > среды. Сизиф сейчас дружественен пользователю и мэйнтейнеру, но враждебен
> > разработчику.
>
> Полный набор gcc тоже даёт проблемы.
<skip >
> Но если речь идёт о базовом системном интерпретаторе, который служит
> ОСНОВОЙ для порождения иерархии зависимостей, тогда эта проблема
> возникает часто и стоит остро.

Да, это я понял.

Правильно ли я понял, что возможна такая ситуация:

 * в Сизифе начинает жить питон 2.5, он же просто питон
 * в Сизифе будет жить питон 2.4, который будет собран с отключенными 
провайдесами, которого никто автоматом не затребует, но который можно будет 
установить и использовать как `/usr/bin/env python2.4`

?

Насколько возможно сделать так, чтобы при этом python 2.4 цеплял модули .py 
(не использующие .so), "собранные" под 2.5 (он при этом попробует 
переделать .pyc, но это уже проблема человека, который ставить python2.4)?

Насколько возможна ситуация, когда энтузиасты смогут при этом собирать и 
модули с .so под 2.4 при всём при этом? Опять-таки, на тех же условиях, что и 
весь остальной питон 2.4 -- не мешать 2.5?

...

Задача-максимум, как я её вижу -- дать человеку возможность установить питон 
2.4, если это ему уж так надо, а также модули к нему -- руками. Ну, через 
apt-get. Разработчики обычно знают, какие модули нужны, и способны обойтись 
без вселенского разума в определении зависимостей, так что это нормально.

-- 
Peter V. Saveliev

Re: [devel] python vs gcc

[Andrey Orlov]

On Sunday 28 October 2007 21:43:56 Peter V. Saveliev wrote:
> Правильно ли я понял, что возможна такая ситуация:
>
>  * в Сизифе начинает жить питон 2.5, он же просто питон
>  * в Сизифе будет жить питон 2.4, который будет собран с отключенными
> провайдесами, которого никто автоматом не затребует, но который можно будет
> установить и использовать как `/usr/bin/env python2.4`
> Насколько возможно сделать так, чтобы при этом python 2.4 цеплял модули .py
> (не использующие .so), "собранные" под 2.5 (он при этом попробует
> переделать .pyc, но это уже проблема человека, который ставить python2.4)?
>
> Насколько возможна ситуация, когда энтузиасты смогут при этом собирать и
> модули с .so под 2.4 при всём при этом? Опять-таки, на тех же условиях, что
> и весь остальной питон 2.4 -- не мешать 2.5?

Насколько я помню, еще несколько лет назад, такая ситуация была полностью 
работоспособна: два питона могли быть установлены вместе, выбор питона 
переключался либо альтернативой либо явным указаним при запуске программы,
можно было собрать два раздельных комплекта модулей, с коорректно 
установленными зависимостями, при чем, за исключением
случаев патологической несовместимости, из одних исходников (фактически при 
первой сборке указывалась ключем версия, которая потом сохранялась и 
выдерживала пересборку, как Алексей этого достиг я не знаю, но достиг).

И все это друг другу не мешало. Зависимости все поддерживались и все вместе 
ставилось. Я это знаю абсолютно точно, так как в связи с особенностями того, 
чем я тогда занимался, использовал это постоянно.

Неужели за столь короткое время все это было утеряно? 

> Задача-максимум, как я её вижу -- дать человеку возможность установить
> питон 2.4, если это ему уж так надо, а также модули к нему -- руками. Ну,
> через apt-get. Разработчики обычно знают, какие модули нужны, и способны
> обойтись без вселенского разума в определении зависимостей, так что это
> нормально.

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

-- 
Andrey Orlov aka "Cray", Редактор
+ 79262229963, http://www.zope3.ru

Re: [devel] python vs gcc

[Peter V. Saveliev]

В сообщении от Friday 02 November 2007 09:21:37 Andrey Orlov написал(а):
<skip />
> Насколько я помню, еще несколько лет назад, такая ситуация была полностью
> работоспособна: два питона могли быть установлены вместе, выбор питона
> переключался либо альтернативой либо явным указаним при запуске программы,
> можно было собрать два раздельных комплекта модулей, с коорректно
> установленными зависимостями, при чем, за исключением
> случаев патологической несовместимости, из одних исходников (фактически при
> первой сборке указывалась ключем версия, которая потом сохранялась и
> выдерживала пересборку, как Алексей этого достиг я не знаю, но достиг).
>
> И все это друг другу не мешало. Зависимости все поддерживались и все вместе
> ставилось. Я это знаю абсолютно точно, так как в связи с особенностями
> того, чем я тогда занимался, использовал это постоянно.
>
> Неужели за столь короткое время все это было утеряно?

Похоже, таки да.

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

Дык увы нам всем.

-- 
Peter V. Saveliev

Re: [devel] python vs gcc

[Andrey Orlov]

On Friday 02 November 2007 10:25:36 Peter V. Saveliev wrote:
> > вместе ставилось. Я это знаю абсолютно точно, так как в связи с
> > особенностями того, чем я тогда занимался, использовал это постоянно.
> >
> > Неужели за столь короткое время все это было утеряно?
>
> Похоже, таки да.

Жаль. 

-- 
Andrey Orlov aka "Cray", Редактор
+ 79262229963, http://www.zope3.ru

Re: [devel] python vs gcc

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [071102 09:44]:
> И все это друг другу не мешало. Зависимости все поддерживались
> и все вместе ставилось.
Дащаз.  Если бы кто-то не изобрёл python-strict, может быть оно
бы и работало.

Нет, я не спорю, может быть в твоём идеальном мире оно до сих пор
работает, но на одних математических доказательствах и чтении
полиси далеко не уедешь.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

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

Re: [devel] python vs gcc

[Andrey Orlov]

On Friday 02 November 2007 12:20:07 Alexey I. Froloff wrote: 
> Дащаз.  Если бы кто-то не изобрёл python-strict, может быть оно
> и работало.

apt-get install python-relaxed? Вроде работает до сих пор. 

> Нет, я не спорю, может быть в твоём идеальном мире оно до сих пор
> работает, но на одних математических доказательствах и чтении
> полиси далеко не уедешь.

Вас мне тоже жаль :)

-- 
Andrey Orlov aka "Cray", Редактор
+ 79262229963, http://www.zope3.ru

Re: [devel] python vs gcc

[Alexey I. Froloff]

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

* Andrey Orlov <cray@> [071103 12:19]:
> > Дащаз.  Если бы кто-то не изобрёл python-strict, может быть оно
> > и работало.
> apt-get install python-relaxed? Вроде работает до сих пор. 
Ага.  "А кто зависит от python-strict - ССЗБ" и "моё питонье
полиси математически доказано, читайте его до просветления".

Впрочем, мне надоело с тобой спорить на эту тему.

-- 
Regards,
Sir Raorn.

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

Re: [devel] python vs gcc

[Andrey Orlov]

On Saturday 03 November 2007 17:07:53 Alexey I. Froloff wrote:
> * Andrey Orlov <cray@> [071103 12:19]:
> > > Дащаз.  Если бы кто-то не изобрёл python-strict, может быть оно
> > > и работало.
> >
> > apt-get install python-relaxed? Вроде работает до сих пор.
>
> Ага.  "А кто зависит от python-strict - ССЗБ" и "моё питонье
> полиси математически доказано, читайте его до просветления".
>
> Впрочем, мне надоело с тобой спорить на эту тему.

Хм. Я с вами и не спорил :). А цитатка "моё питонье полиси математически 
доказано, читайте его до просветления" откуда? 

-- 
Andrey Orlov aka "Cray", Редактор
+ 79262229963, http://www.zope3.ru
-- 
"CRAY" aka Andrey Orlov, ведущий инженер
Информационная Промышленная Группа, 
http://www.iig.ru, +79262229963

Re: [devel] Переходное полиси для для питона

[Aleksey Avdeev]

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

Alexey I. Froloff пишет:
> * Aleksey Avdeev <solo@> [071028 07:15]:
> 
>>1. В системе есть /usr/bin/pythonX.Y. И их может быть несколько.
>>2. В системе есть /usr/bin/python, как указатель на некоторый
>>/usr/bin/pythonX.Y. И данная ссылка может предоставляться несколькими
>>_взаимоконфликтующими_ пакетами.
> 
> Уже проходили.  Почитай мои матюки на тему python2.3->python2.4.

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

  От автоматики я и предлагаю отказаться: если нужен альтернативный
питон -- его придётся _явно_ указывать в спеке. Если указания нет --
сборка идёт _строго_ с текущим для дистрибутива.

> 
> У нас один perl, один tcl, один ruby.  Почему python должен быть
> каким-то особенным?  Только в силу своей кривости?

  Наличие нескольких альтернатив для интерпретаторов считаю правильным.
Если данный вариант будет отлажен на питоне -- можно будет ввести и для
остальных... С чего-то начинать надо. :-)

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] Переходное полиси для для питона

[Sergey Bolshakov]

>>>>> "Aleksey" == Aleksey Avdeev <solo@solin.spb.ru> writes:

 > Alexey I. Froloff пишет:
 >> * Aleksey Avdeev <solo@> [071028 07:15]:
 >> 
 >>> 1. В системе есть /usr/bin/pythonX.Y. И их может быть несколько.
 >>> 2. В системе есть /usr/bin/python, как указатель на некоторый
 >>> /usr/bin/pythonX.Y. И данная ссылка может предоставляться несколькими
 >>> _взаимоконфликтующими_ пакетами.
 >> 
 >> Уже проходили.  Почитай мои матюки на тему python2.3->python2.4.

[skipped]

 >   Наличие нескольких альтернатив для интерпретаторов считаю правильным.
 > Если данный вариант будет отлажен на питоне -- можно будет ввести и для
 > остальных... С чего-то начинать надо. :-)

Надо ли ? С этого ли ?
Не лучше ли было бы довести подсистему python c единственным
интерпретатором до приличного состояния, хотя бы в целях
демонстрации высокого уровня концепций blablabla.
Дорогие питоноводы! Доведите до ума один питон; не прыгайте
через ступеньки !

-- 

Re: [devel] Переходное полиси для для питона

[Aleksey Avdeev]

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

Sergey Bolshakov пишет:
>>>>>>"Aleksey" == Aleksey Avdeev <solo@solin.spb.ru> writes:
> 
> 
>  > Alexey I. Froloff пишет:
>  >> * Aleksey Avdeev <solo@> [071028 07:15]:
>  >> 
>  >>> 1. В системе есть /usr/bin/pythonX.Y. И их может быть несколько.
>  >>> 2. В системе есть /usr/bin/python, как указатель на некоторый
>  >>> /usr/bin/pythonX.Y. И данная ссылка может предоставляться несколькими
>  >>> _взаимоконфликтующими_ пакетами.
>  >> 
>  >> Уже проходили.  Почитай мои матюки на тему python2.3->python2.4.
> 
> [skipped]
> 
>  >   Наличие нескольких альтернатив для интерпретаторов считаю правильным.
>  > Если данный вариант будет отлажен на питоне -- можно будет ввести и для
>  > остальных... С чего-то начинать надо. :-)
> 
> Надо ли ? С этого ли ?

  Некоторое давно устаревшее, но крайне необходимое для чьего то бизнеса
приложение (из тех, под работу которых точится система, а не на оборот)
всегда может всплыть в самый "подходящий" момент. А ресурсов для запила
его под дистрибутив может и не быть (да и не всегда оно
нужно/желательно). (Было у меня такое несколько раз на практике... Как
раз с питоном.)

> Не лучше ли было бы довести подсистему python c единственным
> интерпретатором до приличного состояния, хотя бы в целях
> демонстрации высокого уровня концепций blablabla.
> Дорогие питоноводы! Доведите до ума один питон; не прыгайте
> через ступеньки !

  +1

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

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] Переходное полиси для для питона

[Alexey I. Froloff]

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

* Aleksey Avdeev <solo@> [071028 13:46]:
>   От автоматики я и предлагаю отказаться: если нужен альтернативный
> питон -- его придётся _явно_ указывать в спеке. Если указания нет --
> сборка идёт _строго_ с текущим для дистрибутива.
ЕДИНСТВЕННЫЙ возможный вариант иметь в репозитарии несколько
версий питона - это собирать основной питон без версий, а все
дополнительные в виде pythonX.Y и зависимостями вида pythonX.Y().
Иначе будет жопа.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Переходное полиси для для питона

[Aleksey Avdeev]

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

Alexey I. Froloff пишет:
> * Aleksey Avdeev <solo@> [071028 13:46]:
> 
>>  От автоматики я и предлагаю отказаться: если нужен альтернативный
>>питон -- его придётся _явно_ указывать в спеке. Если указания нет --
>>сборка идёт _строго_ с текущим для дистрибутива.
> 
> ЕДИНСТВЕННЫЙ возможный вариант иметь в репозитарии несколько
> версий питона - это собирать основной питон без версий, а все
> дополнительные в виде pythonX.Y и зависимостями вида pythonX.Y().
> Иначе будет жопа.

  Про это -- я и веду речь.

  Но ограничение единственности основного питона излишне: И пусть его
предоставляют несколько _взаимоконфликтующих_ пакетов. По моему такого
ограничения достаточно. (В конкретный дистрибутив вполне может уходить
только один из них.)

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] Переходное полиси для для питона

[Alexey I. Froloff]

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

* Aleksey Avdeev <solo@> [071028 14:27]:
> > ЕДИНСТВЕННЫЙ возможный вариант иметь в репозитарии несколько
> > версий питона - это собирать основной питон без версий, а все
> > дополнительные в виде pythonX.Y и зависимостями вида pythonX.Y().
> > Иначе будет жопа.
>   Про это -- я и веду речь.
Никто не запрещает так делать.

>   Но ограничение единственности основного питона излишне: И пусть его
> предоставляют несколько _взаимоконфликтующих_ пакетов.
Уже проходили.  Половина репозитария зависит от одного питона,
половина от другого.  В результате имеем жопу.  Спасибо, наелись
прошлый раз.  Кроме фразы "читайте полиси, я математически
доказал его правильность" от тогдашнего мантейнера питона больше
ничего не было слышно.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Переходное полиси для для питона

[Aleksey Avdeev]

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

Alexey I. Froloff пишет:
> * Aleksey Avdeev <solo@> [071028 14:27]:
> 
>>>ЕДИНСТВЕННЫЙ возможный вариант иметь в репозитарии несколько
>>>версий питона - это собирать основной питон без версий, а все
>>>дополнительные в виде pythonX.Y и зависимостями вида pythonX.Y().
>>>Иначе будет жопа.
>>
>>  Про это -- я и веду речь.
> 
> Никто не запрещает так делать.
> 
> 
>>  Но ограничение единственности основного питона излишне: И пусть его
>>предоставляют несколько _взаимоконфликтующих_ пакетов.
> 
> Уже проходили.  Половина репозитария зависит от одного питона,
> половина от другого.  В результате имеем жопу.  Спасибо, наелись
> прошлый раз.  Кроме фразы "читайте полиси, я математически
> доказал его правильность" от тогдашнего мантейнера питона больше
> ничего не было слышно.

  Не вижу в этом большой опасности, _если_ политика определения и
использования _текущего_ питона и смены его версии прописаны _явно_. Не
вызывает же проблем наличие в репозитарии разных версий одной и той-же
библиотеки?

PS: Я не вижу, чем случай с версиями питона от случая с библиотеками
существенно отличается -- только меньшей фармализованностью на _данный_
момент...

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] Переходное полиси для для питона

[Alexey Tourbin]

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

On Sun, Oct 28, 2007 at 02:17:31PM +0300, Alexey I. Froloff wrote:
> * Aleksey Avdeev <solo@> [071028 13:46]:
> >   От автоматики я и предлагаю отказаться: если нужен альтернативный
> > питон -- его придётся _явно_ указывать в спеке. Если указания нет --
> > сборка идёт _строго_ с текущим для дистрибутива.
> ЕДИНСТВЕННЫЙ возможный вариант иметь в репозитарии несколько
> версий питона - это собирать основной питон без версий, а все
> дополнительные в виде pythonX.Y и зависимостями вида pythonX.Y().
> Иначе будет жопа.

ГОРАЗДО ХУЖЕ.  Нельзя иметь дефолтный питон без версии.
Иначе при обновлении дефолтного питона 2.4 -> 2.5 происходит
"динамическое переключение" альтернативных иерархий зависимостей:
python(...) -> python2.4(...).

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

Re: [devel] Переходное полиси для для питона

[Alexey I. Froloff]

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

* Alexey Tourbin <at@> [071028 14:57]:
> ГОРАЗДО ХУЖЕ.  Нельзя иметь дефолтный питон без версии.
> Иначе при обновлении дефолтного питона 2.4 -> 2.5 происходит
> "динамическое переключение" альтернативных иерархий зависимостей:
> python(...) -> python2.4(...).
Тогда при изменении версии дефолтного питона придётся
пересобирать всё что имеет зависимости на pythonX.Y() одной
большой пачкой...  С другой стороны сразу будет видно, что
сломалось.

Надо сказать, что у тебя такие большие пересборки получаются
очень хорошо ;-)

-- 
Regards,
Sir Raorn.

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

Re: [devel] Переходное полиси для для питона

[Andrey Orlov]

On Sunday 28 October 2007 13:38:31 Aleksey Avdeev wrote:
>   От автоматики я и предлагаю отказаться: если нужен альтернативнй
> питон -- его придётся _явно_ указывать в спеке. Если указания нет --
> сборка идёт _строго_ с текущим для дистрибутива.

Причем, если я правильно помню, кривую автоматику исправил Алексей еще два 
года назад. Я, правда, тогда уже не занимался питоном.

-- 
Andrey Orlov aka "Cray", Редактор
+ 79262229963, http://www.zope3.ru

Re: [devel] Переходное полиси для для питона

[Alexey Tourbin]

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

On Sun, Oct 28, 2007 at 01:08:10PM +0300, Alexey I. Froloff wrote:
> * Aleksey Avdeev <solo@> [071028 07:15]:
> > 1. В системе есть /usr/bin/pythonX.Y. И их может быть несколько.
> > 2. В системе есть /usr/bin/python, как указатель на некоторый
> > /usr/bin/pythonX.Y. И данная ссылка может предоставляться несколькими
> > _взаимоконфликтующими_ пакетами.
> Уже проходили.  Почитай мои матюки на тему python2.3->python2.4.
> 
> У нас один perl, один tcl, один ruby.  Почему python должен быть
> каким-то особенным?  Только в силу своей кривости?

Питон особенный, как и перл, но не tcl и ruby, потому что мы
считаем перл и питон базовыми системными интерпретаторми --
поддержка этих языков есть в базовой сборочной среде.
Никаких диверсий по зависимостям здесь быть не должно.

Если кто-то хочет собирать python2.4, то у меня единственное
требование -- отключить системный поиск питоновских зависимостей:
AutoReqProv: yes, nopython.  И естественно чтобы он не претендовал
на /usr/bin/python и т.п.

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

Re: [devel] Переходное полиси для для питона

[Peter V. Saveliev]

В сообщении от Sunday 28 October 2007 17:12:03 Alexey Tourbin написал(а):
<skip />
> Питон особенный, как и перл, но не tcl и ruby, потому что мы
> считаем перл и питон базовыми системными интерпретаторми --
> поддержка этих языков есть в базовой сборочной среде.
> Никаких диверсий по зависимостям здесь быть не должно.
>
> Если кто-то хочет собирать python2.4, то у меня единственное
> требование -- отключить системный поиск питоновских зависимостей:
> AutoReqProv: yes, nopython.  И естественно чтобы он не претендовал
> на /usr/bin/python и т.п.

Само собой. Попробуем. Ты только объяви час Х, чтобы я (или кто-то ещё, кому 
python2.4 будет дорог) мог подхватить вовремя, отправив в Сизиф сборку 
питона.

-- 
Peter V. Saveliev

Re: [devel] Переходное полиси для для питона

[Alexey Tourbin]

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

On Sun, Oct 28, 2007 at 07:10:14AM +0300, Aleksey Avdeev wrote:
> > ПОЧЕМУ: сейчас дефолтный питон /usr/bin/python версии 2.4 и зависимости
> > у пакетов имеют вид python2.4(...).  Если обновить дефолтный
> > /usr/bin/python на 2.5, то зависимости у всех остальных пакетов никуда
> > не денутся, они останутся python2.4(...).  Теперь подумайте, что
> > получается, когда питон обновился, а скрипт, запускаемый через
> > /usr/bin/python имеет зависимости на питон 2.4, а на самом деле в
> > системе стоит питон 2.5.  Например, этот скрипт для работы требует
> > что-то типа python2.4(gtk).  Но при запуске через новый /usr/bin/python
> > эта зависимость как бы динамически трансформируется на python2.5(gtk).
> > То есть зависимость может быть формально удовлетворена, но получается
> > пшик, скрипт не запускается потому что уже нужен gtk'шный модуль для
> > 2.5, а не для 2.4.
> 
>   Так может достаточно отделить мух от котлет? Например так:
> 
> 1. В системе есть /usr/bin/pythonX.Y. И их может быть несколько.
> 
> 2. В системе есть /usr/bin/python, как указатель на некоторый
> /usr/bin/pythonX.Y. И данная ссылка может предоставляться несколькими
> _взаимоконфликтующими_ пакетами.

Подобную схему изобретал Андрей Оролов.

> 3. При сборке пакета со скриптами использующими /usr/bin/python --
> добавляем в их зависимость на пакет предоставляющий /usr/bin/python в
> сборочной среде. В идеале, здесь желательно иметь ручку, отключающую
> данное поведение: её можно использовать для получения пакетов работающих
> с неким диапазоном версий питонов -- возможность поставить конфликты на
> те версии с которыми скрипт не работает у мантейнера останется.
> 
>   Тогда мы имеем с гуся следующее:
> 
> 1. Пакеты со скриптами использующими /usr/bin/pythonX.Y напрямую --
> спокойно продолжают это делать, независимо от версии /usr/bin/python
> установленной в системе.
> 
> 2. Если в пакете используется /usr/bin/python -- при установке будет
> попытка вытянуть нужную версию (ту, с которой пакет был собран). Если
> это приведёт к конфликтам -- ставящий будет вынужден разрешить их в
> ручную (и это правильно).

*)

> 3. Пакет которому необходим старый питон -- для не конфликтности с новым
> достаточно просто пропатчить.
> 
> 4. Возможно плавное замещение питона в дистрибутиве. (Но не на
> конкретной системе! Там, в прочем, возможен выбор _момента_ перехода.)

Невозможно, в силу *).  Просто часть пакетов будет ставиться только
со старым питоном, часть -- только с новым.   Часть пакетов вообще не
будет ставиться, потому что будет попытка поставить два питона.

> > Я делаю системное решение.  То есть я исхожу из того, что все пакеты
> > В РЕПОЗИТАРИИ должны будут работать/починиться под новый питон.
> > Что там запускается из /home/user мне не особо интересно.  Если там есть
> > что-то важное, то нужно это опакетить, и тогда придётся учитывать этот
> > пакет в плане миграции на питон 2.5.
> 
>   Этот вариант идеален, но я не чую его жизнеспособности в условиях
> ограниченности ресурсов. :-/
> 
>   При вашем варианте имеем следующие грабли:
> 
> 1. Задержка на попадание нового питона в Сизиф, пока не будет
> оттестировано всё, что будет сочтено "ядром питона"

Думаю, что достаточно чтобы оно пересобралось с новым питоном.
Я не знаю, есть ли в питоновских пакетах привычка писать что-нибудь
вроде 'make test'.  Это могло бы сделать первичное тестирование
существенно более предсказуемым.

> 2. При появлении нового питона в Сизифе -- часть приложений (что в
> "ядром питона" не вошла) "неожиданно" перестанет работать.

Они и так перестают работать.  Достаточно пересобрать какой-нибудь
"средний" по топологии зависимостей питоновский модуль и вся иерархия
пакетов рассыпается -- возникает диверсия, при которой часть пакетов
относятся к старому питону, а часть -- уже к новому.

> 3. Калуарность тестирования нового питона (т. к. помещать его в Сизиф,
> пока "ядром питона" не оттестировано/портировано -- нельзя).

Можно делать так как я делал с rpm-build.  То есть запускаем тестовую
пересборку и смотрим какие есть проблемы.  Решаем часть проблем, опять
запускаем тестовую пересборку.  Проблем стало меньше.  Тогда
окончательно пускаем в сизиф.

Кулуарности никакой нет -- напротив, тому, кто за это взялся, придётся
очень много объяснять по поводу "типичных проблем" и т.д.

>   Причём, за счёт того что для каждого использующего питон "ядром
> питона" своё, и с "ядром питона" коллег совпадать не обязано -- получаем
> источник конфликтов в рассылке...

"Ядро питона" это все про-питоновские пакеты в сизифе.
Минимальный план миграции -- просто пересобрать их с новым питоном.
Мне хотелось бы, чтобы при этом они ещё и работали.  Для этого нужно
какое-то минимальное тестирование при СБОРКЕ.  Хотя бы после сборки
попробовать загрузить питоном свежесобранные модули.

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

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

Re: [devel] Переходное полиси для для питона

[Aleksey Avdeev]

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

Alexey Tourbin пишет:
> On Sun, Oct 28, 2007 at 07:10:14AM +0300, Aleksey Avdeev wrote:
> 
>>>ПОЧЕМУ: сейчас дефолтный питон /usr/bin/python версии 2.4 и зависимости
>>>у пакетов имеют вид python2.4(...).  Если обновить дефолтный
>>>/usr/bin/python на 2.5, то зависимости у всех остальных пакетов никуда
>>>не денутся, они останутся python2.4(...).  Теперь подумайте, что
>>>получается, когда питон обновился, а скрипт, запускаемый через
>>>/usr/bin/python имеет зависимости на питон 2.4, а на самом деле в
>>>системе стоит питон 2.5.  Например, этот скрипт для работы требует
>>>что-то типа python2.4(gtk).  Но при запуске через новый /usr/bin/python
>>>эта зависимость как бы динамически трансформируется на python2.5(gtk).
>>>То есть зависимость может быть формально удовлетворена, но получается
>>>пшик, скрипт не запускается потому что уже нужен gtk'шный модуль для
>>>2.5, а не для 2.4.
>>
>>  Так может достаточно отделить мух от котлет? Например так:
>>
>>1. В системе есть /usr/bin/pythonX.Y. И их может быть несколько.
>>
>>2. В системе есть /usr/bin/python, как указатель на некоторый
>>/usr/bin/pythonX.Y. И данная ссылка может предоставляться несколькими
>>_взаимоконфликтующими_ пакетами.
> 
> 
> Подобную схему изобретал Андрей Оролов.

  И достаточно весомо аргументировал её право на жизнь. (Более того --
мне пришлось столкнуться с её плюсами.)

> 
> 
>>3. При сборке пакета со скриптами использующими /usr/bin/python --
>>добавляем в их зависимость на пакет предоставляющий /usr/bin/python в
>>сборочной среде. В идеале, здесь желательно иметь ручку, отключающую
>>данное поведение: её можно использовать для получения пакетов работающих
>>с неким диапазоном версий питонов -- возможность поставить конфликты на
>>те версии с которыми скрипт не работает у мантейнера останется.
>>
>>  Тогда мы имеем с гуся следующее:
>>
>>1. Пакеты со скриптами использующими /usr/bin/pythonX.Y напрямую --
>>спокойно продолжают это делать, независимо от версии /usr/bin/python
>>установленной в системе.
>>
>>2. Если в пакете используется /usr/bin/python -- при установке будет
>>попытка вытянуть нужную версию (ту, с которой пакет был собран). Если
>>это приведёт к конфликтам -- ставящий будет вынужден разрешить их в
>>ручную (и это правильно).
> 
> 
> *)
> 
> 
>>3. Пакет которому необходим старый питон -- для не конфликтности с новым
>>достаточно просто пропатчить.
>>
>>4. Возможно плавное замещение питона в дистрибутиве. (Но не на
>>конкретной системе! Там, в прочем, возможен выбор _момента_ перехода.)
> 
> 
> Невозможно, в силу *).  Просто часть пакетов будет ставиться только
> со старым питоном, часть -- только с новым.   Часть пакетов вообще не
> будет ставиться, потому что будет попытка поставить два питона.

  По моему это уже не технический аспект, а организационный: достаточно
_явно_ указать в полиси что отсутствие пакета под текущий питон
переводит его в статус, равнозначный его отсутствию (с некоторыми
ограничениями, возможно).

> 
> 
>>>Я делаю системное решение.  То есть я исхожу из того, что все пакеты
>>>В РЕПОЗИТАРИИ должны будут работать/починиться под новый питон.
>>>Что там запускается из /home/user мне не особо интересно.  Если там есть
>>>что-то важное, то нужно это опакетить, и тогда придётся учитывать этот
>>>пакет в плане миграции на питон 2.5.
>>
>>  Этот вариант идеален, но я не чую его жизнеспособности в условиях
>>ограниченности ресурсов. :-/
>>
>>  При вашем варианте имеем следующие грабли:
>>
>>1. Задержка на попадание нового питона в Сизиф, пока не будет
>>оттестировано всё, что будет сочтено "ядром питона"
> 
> 
> Думаю, что достаточно чтобы оно пересобралось с новым питоном.
> Я не знаю, есть ли в питоновских пакетах привычка писать что-нибудь
> вроде 'make test'.  Это могло бы сделать первичное тестирование
> существенно более предсказуемым.

  Теоретически -- да, это то к чему надо стремиться. Но случаи
прикладной некромантии тоже существенны.

> 
> 
>>2. При появлении нового питона в Сизифе -- часть приложений (что в
>>"ядром питона" не вошла) "неожиданно" перестанет работать.
> 
> 
> Они и так перестают работать.  Достаточно пересобрать какой-нибудь
> "средний" по топологии зависимостей питоновский модуль и вся иерархия
> пакетов рассыпается -- возникает диверсия, при которой часть пакетов
> относятся к старому питону, а часть -- уже к новому.

  Если это произошло после отмашки "текущий питон X.Y" -- то не вижу
проблемы: в любом случаи не вижу способа избежать частичной
разломанности репозитария.

  Возможно неплохим вариантом будет полиси аналогичное описывающему
смену сонаме для библиотек. Например так:

1. Пакет для текущего питона называется python-<имя>.

2. Для питона отличного от текущего -- pythonX.Y-<имя>.

> 
> 
>>3. Калуарность тестирования нового питона (т. к. помещать его в Сизиф,
>>пока "ядром питона" не оттестировано/портировано -- нельзя).
> 
> 
> Можно делать так как я делал с rpm-build.  То есть запускаем тестовую
> пересборку и смотрим какие есть проблемы.  Решаем часть проблем, опять
> запускаем тестовую пересборку.  Проблем стало меньше.  Тогда
> окончательно пускаем в сизиф.

  Как при этом _простым_ образом решать проблемы с зависимостями от
пакетов другого мантейнера?

  Да, git.alt часть проблем закроет... Но возможность вытащить из
репозитария подходящий pythonX.Y-<имя> (если он уже есть), собранный его
мантейнером, на мой взгляд не лишняя.

> 
> Кулуарности никакой нет -- напротив, тому, кто за это взялся, придётся
> очень много объяснять по поводу "типичных проблем" и т.д.
> 
> 
>>  Причём, за счёт того что для каждого использующего питон "ядром
>>питона" своё, и с "ядром питона" коллег совпадать не обязано -- получаем
>>источник конфликтов в рассылке...
> 
> 
> "Ядро питона" это все про-питоновские пакеты в сизифе.
> Минимальный план миграции -- просто пересобрать их с новым питоном.
> Мне хотелось бы, чтобы при этом они ещё и работали.  Для этого нужно
> какое-то минимальное тестирование при СБОРКЕ.  Хотя бы после сборки
> попробовать загрузить питоном свежесобранные модули.
> 
> То есть пересобираемость пакета должна давать минимальную гарантию
> его работоспособности.  Тогда получается технологичное решение.
> Иначе, действительно, остается только "источник конфликтов в рассылке".

  Согласен. Но ручка для явного переключения на pythonX.Y всё равно не
лишняя.

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] Переходное полиси для для питона

[Alexey Tourbin]

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

On Sun, Oct 28, 2007 at 03:36:00PM +0300, Aleksey Avdeev wrote:
> > Думаю, что достаточно чтобы оно пересобралось с новым питоном.
> > Я не знаю, есть ли в питоновских пакетах привычка писать что-нибудь
> > вроде 'make test'.  Это могло бы сделать первичное тестирование
> > существенно более предсказуемым.
> 
>   Теоретически -- да, это то к чему надо стремиться. Но случаи
> прикладной некромантии тоже существенны.

Нет.  Я могу делать только стабильный репозитарий с определенным
дизайном и как бы правилами игры.  Некромантия в эти правила не входит.

Если противоречия в рассылке достигнут апогея, то я, во-первых, не буду
собирать питон 2.5, а во-вторых, отрву rpm-build-python от базовой
сборочной среды.  Тогда питон перейдёт в разряд маргинальных пакетов
и будет ждать новых героев.  Я предупредил. :)

> 1. Пакет для текущего питона называется python-<имя>.
> 2. Для питона отличного от текущего -- pythonX.Y-<имя>.

Надёжный "системный" поиск зависимостей плохо совместим
с альтернативными иерархиями зависимостей.  Это РЕАЛЬНО
создает проблемы, которые в лучшем случае можно решить лишь частично.

> > Можно делать так как я делал с rpm-build.  То есть запускаем тестовую
> > пересборку и смотрим какие есть проблемы.  Решаем часть проблем, опять
> > запускаем тестовую пересборку.  Проблем стало меньше.  Тогда
> > окончательно пускаем в сизиф.
> 
>   Как при этом _простым_ образом решать проблемы с зависимостями от
> пакетов другого мантейнера?

А как два питона решает проблемы с зависимостями?
Пакет A зависит от питона X.Y, пакет B зависит от питона X.Z.
Пакет С зависит от пакетов A и B.

Это что же получается?  Два питона -- это просто способ маскировать
анметы?

Никакой новой проблемы с зависимостями здесь нет.  Есть рутинная
проблема адаптации пакетов к новой среде.

>   Да, git.alt часть проблем закроет... Но возможность вытащить из
> репозитария подходящий pythonX.Y-<имя> (если он уже есть), собранный его
> мантейнером, на мой взгляд не лишняя.

Этих героев нет.  Насколько я вижу, сейчас большая часть питоновских
пакетов собирается по остаточному принципу.  Соответственно, идейная
программа сейчас -- это выжать максимум из остаточного принципа.

Более того, у меня есть такое наблюдение, что люди, которые в принципе
могли бы грамотно взяться за два питона, они занимаются чем-то ещё.
При этом до конца все "двухпитоновские" проблемы всё равно решть бы не
удалось.

> > То есть пересобираемость пакета должна давать минимальную гарантию
> > его работоспособности.  Тогда получается технологичное решение.
> > Иначе, действительно, остается только "источник конфликтов в рассылке".
> 
>   Согласен. Но ручка для явного переключения на pythonX.Y всё равно не
> лишняя.

Вы знаете, я люблю жену, а ещё мне нравится Бритни Спирс.
Говорят даже что она вступала в половые отношения с некоторыми мужчинами.
Ручка для явного переключения была бы не лишней.

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