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

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

[Alexey Tourbin]

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

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

В обозримом будущем планируется переход на питон 2.5.
В связи с этим дальше лелеять надежны насчёт двух питонов я не вижу
смысла.

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

Я предлагаю переходное полиси для питона.  Оно устремлено к переходу
на 2.5, но его можно использовать уже сейчас.  В двух словах это полиси
состоит в том, что никакого полиси в общем-то нет.  Питоновские пакеты
не считаются какими-то особенными и не требуют специального полиси.

Предлагаю делать следующее.

0) Установить python-dev 2.4.4-alt13 (залит в incoming,
скоро будет в сизифе).
1) Вычистить из python-module-*.spec всё что специфично
для старого полиси.  В частности, не использовать макрос
в %name.
2) Запустить buildreq, который должен проставить зависимость
на python-devel (и на что-то ещё).
3) Убрать все питоновские зависимости, проставленные вручную,
в частности, python = %__python_version.  Поиск зависимостей
был докручен до более юзабельного состояния, и все безусловные
(top-level) зависимости теперь проставляются как в модулях,
так и в скриптах.  Поэтому "жирная" зависимость на python
не нужна (в ряде случаев достаточно python-base).  Также нужно
попробовать вычистить все хаки типа %add_python_req_skip.
Неправильных питоновских анметов теперь в основном не будет.
4) Убедиться, что если модуль компилированный, то у пакета автоматически
появилась зависимость на libpython2.4.so.1.0.  (По этой причине как
минимум у компилированных модулей можно не выставлять зависимость на
версию питона, как того требовало старое полиси).

Короче, предложенное переходное полиси в основном сводится к тому,
чтобы почистить спек и запустить buildreq.  То есть мотивирующая идея
здесь состоит в том, что полиси вгоняется "вглубь" сборочной среды
и реализуется автоматически, а не на уровне дополнительных манипуляций
в spec-файле.  Правда, конструкция становится более жесткой.

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

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

[Peter V. Saveliev]

В сообщении от Friday 26 October 2007 21:23:54 Alexey Tourbin написал(а):
> Похоже, нескольких питонов в репозитарии никогда не будет (по крайней
> мере на системном и хорошо юзабельном уровне).  Кроме того, даже когда
> в репозитарии было два питона, программа сборки дополнительных
> питоновских модулей в двух штуках под каждый питон никогда не была
> реализована (даже частично).
>
> В обозримом будущем планируется переход на питон 2.5.
> В связи с этим дальше лелеять надежны насчёт двух питонов я не вижу
> смысла.
<skip />

* а ничего, что некоторые программы работают только с 2.4?
* в частности, я смогу подгонять свой проект под 2.5 только после его 
появления в Сизифе, по хорошему, т.к. времени, чтобы ставить Debian, просто 
не остаётся

Есть объективная причина, которая исключает наличие двух питонов? Или это как 
с biarch, "некошерно, потому что у нас такого нет", а не наоборот?

-- 
Peter V. Saveliev

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

[Alexey Tourbin]

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

On Fri, Oct 26, 2007 at 10:56:13PM +0400, Peter V. Saveliev wrote:
> > В обозримом будущем планируется переход на питон 2.5.
> > В связи с этим дальше лелеять надежны насчёт двух питонов я не вижу
> > смысла.
> 
> * а ничего, что некоторые программы работают только с 2.4?
> * в частности, я смогу подгонять свой проект под 2.5 только после его 
> появления в Сизифе, по хорошему, т.к. времени, чтобы ставить Debian, просто 
> не остаётся

Уже вышел python 2.5.1 (некоторое время назад).  Все кому надо за это
время должны были "подтянуться" (из апстримов по крайней мере).
Собственно, в свое время я был против перехода на на python 2.5(.0)
как раз потому, что (наверное) не все были готовы.  Но теперь время
будет "играть" в обратную сторону.  Есть ведь и обратная проблема:
апстримы уже не будут сохранять совместимость с 2.4.

> Есть объективная причина, которая исключает наличие двух питонов? Или это как 
> с biarch, "некошерно, потому что у нас такого нет", а не наоборот?

Если отбросить практическую причину (что программа сборки дополнительных
модулей в двух экземлярах так никгода и не была даже частично
реализована), то всё равно это никак нельзя по-нормальному сделать на
уровне rpm-зависимостей.  То есть если /usr/bin/python висит на
альтернативах, то эта альтернатива динамически переключает зависимости
вида pythonX.Y(...) на pythonX.Z(...).  Я про это в свое время много спорил.

Можно будет оставить "чисто запасной" python2.4 с отключенным поиском
питоновских зависимостей и без /usr/bin/python (только с
/usr/bin/python2.4).  Может кто-нибудь этим займется ввиду суровой
необходимости.

К тому же, схема зависимостей pythonX.Y(...) не дает возможность делать
noarch пакеты, которые не должны зависеть от версии python'а.  По идее у
таких пакетов должен быть Provides: python(...).  То как тогда ставить
комплементарный Requires: python(...) или pythonX.Y(...) ?

То есть я полагаю что будет сделано так: будет всего один питон;
будет сделан /usr/share/python/site-packages; все зависимости будут
иметь вид python(...); компилированные пакеты будут дополнительно
иметь зависимость на libpythonX.Y.so.M.N.  Вопрос с совместимостью
версии байткода в noarch пакетах кажется мне непринципиальным -- если
версия байткода в *.pyc не совпадает, питон просто будет загружать *.py.

Всё это будет не в ближайшее время, наверное в следующем году.
Но кое-что к этому уже готово.  Поскольку очень маловероятно,
чтобы кто-то таки начал собирать модули для разных питонов из одного
spec-файла (в чем соль старого полиси), я пока просто предлагаю
постепенно "подчистить" spec-файлы.  Когда наступит час X, придётся
меньше переделывать, часть пакетов можно будет просто пересобрать.

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

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

[Peter V. Saveliev]

В сообщении от Friday 26 October 2007 23:24:31 Alexey Tourbin написал(а):
> On Fri, Oct 26, 2007 at 10:56:13PM +0400, Peter V. Saveliev wrote:
> > > В обозримом будущем планируется переход на питон 2.5.
> > > В связи с этим дальше лелеять надежны насчёт двух питонов я не вижу
> > > смысла.
> >
> > * а ничего, что некоторые программы работают только с 2.4?
> > * в частности, я смогу подгонять свой проект под 2.5 только после его
> > появления в Сизифе, по хорошему, т.к. времени, чтобы ставить Debian,
> > просто не остаётся
>
> Уже вышел python 2.5.1 (некоторое время назад).  Все кому надо за это
> время должны были "подтянуться" (из апстримов по крайней мере).
> Собственно, в свое время я был против перехода на на python 2.5(.0)
> как раз потому, что (наверное) не все были готовы.  Но теперь время
> будет "играть" в обратную сторону.  Есть ведь и обратная проблема:
> апстримы уже не будут сохранять совместимость с 2.4.
>
<skip />

Понимая тяжесть проблем rpm, тем не менее, должен заметить, что это 
симптоматично: чтобы иметь среду для разработки под alt, порой приходится 
использовать или установку в ~, или другой дистрибутив.

Ок.

-- 
Peter V. Saveliev

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

[Alexey Tourbin]

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

On Sat, Oct 27, 2007 at 01:05:22AM +0400, Peter V. Saveliev wrote:
> > Уже вышел python 2.5.1 (некоторое время назад).  Все кому надо за это
> > время должны были "подтянуться" (из апстримов по крайней мере).
> > Собственно, в свое время я был против перехода на на python 2.5(.0)
> > как раз потому, что (наверное) не все были готовы.  Но теперь время
> > будет "играть" в обратную сторону.  Есть ведь и обратная проблема:
> > апстримы уже не будут сохранять совместимость с 2.4.
> >
> <skip />
> 
> Понимая тяжесть проблем rpm, тем не менее, должен заметить, что это 
> симптоматично: чтобы иметь среду для разработки под alt, порой приходится 
> использовать или установку в ~, или другой дистрибутив.

Нельзя никак совместить в репозитарии базовый интерпретатор АЛЬТЕРНАТИВНЫХ
версий и развитую систему автоматического поиска зависимостей.  То есть
при таком подходе нельзя ГАРАНТИРОВАТЬ целостность системы, обязательно
остаются какие-то условия и осмысленные действия которые ДОЛЖЕН
выполнить системный администратор.

В принципе в других дистрибутивах автоматических питоновских
зависимостей нет, и как бы и проблемы нет.  Точнее проблема ещё хуже --
либо писать зависимости вручную (что maintainer'ы так или иначе забывают
делать), либо администратор должен предвидеть ПРАКТИЧЕСКИ ВСЁ.
В принципе, первое не исключает второго.

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

Второй подход более оправдан, потому что у нас мало человеческих
ресурсов, нет возможности всего проверить и всё протестировать в
мало-мальских разных конфигурациях.  Возможностей первичного
тестирования очень мало, приходится закручивать гайки и вставлять
автоматическое тестирование на самых ранних стадиях.

Думаю что эта идея получит развитие.

> Ок.

Так какое Ваше тайное желание, я не совсем понял?  Иметь возможность в
одной и той же хост-системе запустить какой-то питоновский скрипт через
/usr/bin/python2.4 и /usr/bin/python2.5?  Если этот скрипт (почти) не
имеет зависимостей, и ему не нужны дополнительные модули, тогда это
можно сделать относительно просто.  Но два комплекта "тяжелых"
питоновских подсистем нормально сделать никак нельзя.  И этих
двух комплектов никогда не было на самом деле.  То есть я не предлагаю
"это сломать", этого ПРОСТО не было.  Когда перешли с python2.3 на
python2.4, то все дополнительные модули пересобрались для python2.4
и всё.  python2.3 остался "лысым".

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

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

[Peter V. Saveliev]

В сообщении от Saturday 27 October 2007 01:58:18 Alexey Tourbin написал(а):
<skip />
> > Ок.
>
> Так какое Ваше тайное желание, я не совсем понял?
<skip />

Моё тайное желание, на самом деле, вполне явное.

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

Чтобы проект перевести на рельсы питона 2.5, этот питон нужно поиметь. С 
обвязкой в виде модулей, которых немного (ctypes, pyasn1, psnmp*), но есть.

Когда в Сизифе появится питон 2.5, моя прога будет неработоспособна, т.к. я 
точно знаю, что там сломается импорт нескольких модулей. Чтобы это поправить, 
мне нужен питон 2.5 в Сизифе -- в идеальном случае. Либо полное соответствие 
документации на 2.5 (на что я не рассчитываю).

...

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

...

Все беды от того, что когда я разрабатываю, мне нужна платформа для 
разработки. Обидно то, что Сизиф всё больше рассчитан на уже готовые и 
обкатанные решения (см. также тред про миграцию пхп: вариант с единовременной 
заменой хорош только для тех, кто разрабатывает прогу _не_на_альте_, а в 
Сизиф уже идёт только результат разработки).

-- 
Peter V. Saveliev

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

[Alexey Tourbin]

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

On Sat, Oct 27, 2007 at 02:45:00AM +0400, Peter V. Saveliev wrote:
> Все беды от того, что когда я разрабатываю, мне нужна платформа для 
> разработки. Обидно то, что Сизиф всё больше рассчитан на уже готовые и 
> обкатанные решения (см. также тред про миграцию пхп: вариант с единовременной 
> заменой хорош только для тех, кто разрабатывает прогу _не_на_альте_, а в 
> Сизиф уже идёт только результат разработки).

Ладно, философия более-менее понятно.

Вот смотрите, как это в принципе можно сделать?

У меня есть пакет libxml2.  Из него собирается пакет
python-module-libxml2.  Я теперь, допустим, рассматриваю вариант,
как сохранить в сизифе одновременно python2.4 и python2.5 c "жирной"
укомплектацией, которая, конечно же, должна включать в себя питоновский
модуль libxml2.

Я не знаю как это сделать более-менее нормально (и тем интереснее,
как это делается в других дистрибутивах).  То есть мне остается только
из пакета libxml2 собирать несколько питоновских подпакетов для ВСЕХ
СУЩЕСТВУЮЩИХ питонов в сизифе.  Но это плохо параметризуется, даже
в принципе.  В configure проверяется всего один /usr/bin/python.
Его можно заменить на другой /usr/bin/pythonX.Y.  Но два питона
за один раз сделать никак нельзя.

Правда, в %build можно запускать configure два раза и т.д.
Можно делать что-то ещё, но перекраивать базовые системные библиотеки
под два питона этот нонсенс.  А без этого полноценной укомплектации
не получается, и один из питонов остается "лысым".

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

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

[Peter V. Saveliev]

В сообщении от Saturday 27 October 2007 03:02:09 Alexey Tourbin написал(а):
> On Sat, Oct 27, 2007 at 02:45:00AM +0400, Peter V. Saveliev wrote:
> > Все беды от того, что когда я разрабатываю, мне нужна платформа для
> > разработки. Обидно то, что Сизиф всё больше рассчитан на уже готовые и
> > обкатанные решения (см. также тред про миграцию пхп: вариант с
> > единовременной заменой хорош только для тех, кто разрабатывает прогу
> > _не_на_альте_, а в Сизиф уже идёт только результат разработки).
>
> Ладно, философия более-менее понятно.

это голая практика, никакой философии :)

>
> Вот смотрите, как это в принципе можно сделать?

Как разберусь с дженту -- скажу. Гуру по этому дистру заверил, что у него 
стоят оба питона и модули ставятся под оба питона в один присест. С дебом 
пока не знаю, недокачался. Хотя Макс Тюрин говорил вроде, что там тоже 
толстый набор.

Думаю, в конце след. недели у меня будет представление (а заодно и 
оттестированная прога под питон 2.5)

>
> У меня есть пакет libxml2.  Из него собирается пакет
> python-module-libxml2.  Я теперь, допустим, рассматриваю вариант,
> как сохранить в сизифе одновременно python2.4 и python2.5 c "жирной"
> укомплектацией, которая, конечно же, должна включать в себя питоновский
> модуль libxml2.
>
> Я не знаю как это сделать более-менее нормально (и тем интереснее,
> как это делается в других дистрибутивах).  То есть мне остается только
> из пакета libxml2 собирать несколько питоновских подпакетов для ВСЕХ
> СУЩЕСТВУЮЩИХ питонов в сизифе.  

почему-то мэйнтейнеров ядерных модулей это не останавливает.

> Но это плохо параметризуется, даже 
> в принципе.  В configure проверяется всего один /usr/bin/python.
> Его можно заменить на другой /usr/bin/pythonX.Y.  Но два питона
> за один раз сделать никак нельзя.
>
> Правда, в %build можно запускать configure два раза и т.д.
> Можно делать что-то ещё, но перекраивать базовые системные библиотеки
> под два питона этот нонсенс.  А без этого полноценной укомплектации
> не получается, и один из питонов остается "лысым".

Мне кажется, что я готов поддерживать свои питонические библиотеки под два 
питона двойным набором спеков, т.к. это в два > раза меньше спеков, чем под 
разные ядра (std/wks/ovz/xen0/xenU).

-- 
Peter V. Saveliev

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

[Andrey Rahmatullin]

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

On Sat, Oct 27, 2007 at 03:02:09AM +0400, Alexey Tourbin wrote:
> У меня есть пакет libxml2.  Из него собирается пакет
> python-module-libxml2.  Я теперь, допустим, рассматриваю вариант,
> как сохранить в сизифе одновременно python2.4 и python2.5 c "жирной"
> укомплектацией, которая, конечно же, должна включать в себя питоновский
> модуль libxml2.
Package: python-xml
Priority: optional
Section: python
Installed-Size: 3336
Maintainer: Debian/Ubuntu Zope Team
<pkg-zope-developers/lists.alioth.debian.org>
Architecture: i386
Version: 0.8.4-8
Replaces: python2.3-xml, python2.4-xml
Provides: python2.4-xml, python2.5-xml
Depends: python-central (>= 0.5.8), python (<< 2.6), python (>= 2.4),
libc6 (>= 2.6-1)
Suggests: python-xml-dbg
Conflicts: python-4suite (<< 0.12), python2.3-xml, python2.4-xml
Python-Version: 2.4, 2.5

Внутри /usr/share/pycentral/python-xml/site-packages/_xmlplus,
/usr/lib/python2.4/site-packages/_xmlplus и
/usr/lib/python2.5/site-packages/_xmlplus (в libdir лежат .so).


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

> я слышал от тех же дебианщиков, что альт - это урезанный debian. типа
> всё испортили, даже dpkg убрали :))
Как это убрали?
apt-cache show dpkg показывает что на месте. ;-)
		-- icesik in smoke-room@

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

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

[Alexey Tourbin]

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

On Sat, Oct 27, 2007 at 01:58:46PM +0600, Andrey Rahmatullin wrote:
> On Sat, Oct 27, 2007 at 03:02:09AM +0400, Alexey Tourbin wrote:
> > У меня есть пакет libxml2.  Из него собирается пакет
> > python-module-libxml2.  Я теперь, допустим, рассматриваю вариант,
> > как сохранить в сизифе одновременно python2.4 и python2.5 c "жирной"
> > укомплектацией, которая, конечно же, должна включать в себя питоновский
> > модуль libxml2.
> Package: python-xml
> Priority: optional
> Section: python
> Installed-Size: 3336
> Maintainer: Debian/Ubuntu Zope Team
> <pkg-zope-developers/lists.alioth.debian.org>
> Architecture: i386
> Version: 0.8.4-8
> Replaces: python2.3-xml, python2.4-xml
> Provides: python2.4-xml, python2.5-xml
> Depends: python-central (>= 0.5.8), python (<< 2.6), python (>= 2.4),
> libc6 (>= 2.6-1)
> Suggests: python-xml-dbg
> Conflicts: python-4suite (<< 0.12), python2.3-xml, python2.4-xml
> Python-Version: 2.4, 2.5
> 
> Внутри /usr/share/pycentral/python-xml/site-packages/_xmlplus,
> /usr/lib/python2.4/site-packages/_xmlplus и
> /usr/lib/python2.5/site-packages/_xmlplus (в libdir лежат .so).

Это по нашим понятиям python-module-PyXML, а не python-module-libxml2.
Разница довольно существенная.  Первый пакет чисто питоновский, а второй
это системная библиотека, питоновский пакет у него с боку-припёку.
Заводить же в базовых системных библиотеках питоновские порядки неохота.

Кстати, как там обстоит дело с *.pyc и *.pyo?

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

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

[Andrey Rahmatullin]

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

On Sat, Oct 27, 2007 at 06:49:31PM +0400, Alexey Tourbin wrote:
> Это по нашим понятиям python-module-PyXML, а не python-module-libxml2.
> Разница довольно существенная.  Первый пакет чисто питоновский, а второй
> это системная библиотека, питоновский пакет у него с боку-припёку.
> Заводить же в базовых системных библиотеках питоновские порядки неохота.
Мм, а в чём разница? Пакет-то один.

/usr/share/python-support/python-libxml2/libxml2.py
/usr/lib/python-support/python-libxml2/python2.5/libxml2mod.so
/usr/lib/python-support/python-libxml2/python2.4/libxml2mod.so
Оно?

> Кстати, как там обстоит дело с *.pyc и *.pyo?
Лежат на ФС рядом, в пакеты не кладутся, когда компилятся не в курсе.


-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Если бы вы знали, сколько еще пакетов застревает на подходах к Сизифу из-за
претензий по качеству пакетов...

Лучше меньше, да лучше. Можно и больше, но только не хуже.
		-- ldv in sisyphus@

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

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

[Vitaly Lipatov]

On 27 октября 2007, Peter V. Saveliev wrote:
> Чтобы проект перевести на рельсы питона 2.5, этот питон нужно
> поиметь. С обвязкой в виде модулей, которых немного (ctypes,
> pyasn1, psnmp*), но есть.
>
> Когда в Сизифе появится питон 2.5, моя прога будет
> неработоспособна, т.к. я точно знаю, что там сломается импорт
А когда появится glibc-2.7, некоторые проги перестанут 
собираться. и может даже работать.

И вот достаточно много программ перестало собираться из-за 
недавнего обновления intltool:
Global symbol "@INTLTOOL_ICONV" requires explicit package name 
at ../intltool-merge line 94.
BEGIN not safe after errors--compilation aborted 
at ../intltool-merge line 252.

Недели две уже уже не собирается, и ничего, как вчера писали в 
devel@:
"Нормальное решение будет, когда ldv@ посмотрит мои изменения в 
autoconf.git и внесёт их в нашу сборку, надеюсь, на следующей 
неделе у него дойдут до этого руки."

> нескольких модулей. Чтобы это поправить, мне нужен питон 2.5 в
> Сизифе -- в идеальном случае. Либо полное соответствие
> документации на 2.5 (на что я не рассчитываю).
Так а в чём проблема - ну появится 2.5, ну прога немножно 
сломается. За вполне небольшое время можно исправить её, чтобы 
работала и под 2.5. А Сизиф это небольшое время потерпит.
Не так это всё фатально. С 2.5 на 2.4 перетаскивать гораздо 
сложнее, уже немножко пробовали.




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

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

[Peter V. Saveliev]

В сообщении от Saturday 27 October 2007 10:22:14 Vitaly Lipatov написал(а):
> On 27 октября 2007, Peter V. Saveliev wrote:
> > Чтобы проект перевести на рельсы питона 2.5, этот питон нужно
> > поиметь. С обвязкой в виде модулей, которых немного (ctypes,
> > pyasn1, psnmp*), но есть.
> >
> > Когда в Сизифе появится питон 2.5, моя прога будет
> > неработоспособна, т.к. я точно знаю, что там сломается импорт
>
> А когда появится glibc-2.7, некоторые проги перестанут
> собираться. и может даже работать.

Пока работает питон, мне нет большого дела до обновлений glibc, как бы цинично 
это не звучало.

>
> И вот достаточно много программ перестало собираться из-за
> недавнего обновления intltool:

> Global symbol "@INTLTOOL_ICONV" requires explicit package name
> at ../intltool-merge line 94.
> BEGIN not safe after errors--compilation aborted
> at ../intltool-merge line 252.
>
> Недели две уже уже не собирается, и ничего, как вчера писали в
> devel@:
> "Нормальное решение будет, когда ldv@ посмотрит мои изменения в
> autoconf.git и внесёт их в нашу сборку, надеюсь, на следующей
> неделе у него дойдут до этого руки."

Не вижу повода радоваться.

>
> > нескольких модулей. Чтобы это поправить, мне нужен питон 2.5 в
> > Сизифе -- в идеальном случае. Либо полное соответствие
> > документации на 2.5 (на что я не рассчитываю).
>
> Так а в чём проблема - ну появится 2.5, ну прога немножно
> сломается. За вполне небольшое время можно исправить её, чтобы
> работала и под 2.5. А Сизиф это небольшое время потерпит.
> Не так это всё фатально. С 2.5 на 2.4 перетаскивать гораздо
> сложнее, уже немножко пробовали.

Да ни в чём проблемы нет. Уже работаю под 2.5, следующая сборка будет готова к 
обновлению питона.

-- 
Peter V. Saveliev

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

[Максим Иванов]

В сообщении от Saturday 27 October 2007 01:05:22 Peter V. Saveliev написал(а):

>
> Понимая тяжесть проблем rpm, тем не менее, должен заметить, что это
> симптоматично: чтобы иметь среду для разработки под alt, порой приходится
> использовать или установку в ~, или другой дистрибутив.
>
> Ок.

глубоко не вникал как сейчас устроен python в ALT, пользуюсь предельно простым 
методом - virtualenv

юзается просто "virtualenv /path/to/env" и в том каталоге будет создано всё 
необходимое - /path/to/env/usr/bin/python, /pat/to/env/usr/lib/python2.5/site-packages/, 
там же уже будут стоят setuptools. 

Такиих окружений можешь состряпать сколько угодно. Для того что б использовать 
нужное окружение достаточно вызывать ../usr/bin/python или любой другой 
бинарник из соотв. папки (например вызов /path/to/env/usr/bin/easy_install 
sqlalchemy установит пакет именно в то окружение)

Нельзя ли virtualenv скрестить с полиси для питона и сделать его частью 
системы?

ссылка на virtualenv: http://pypi.python.org/pypi/virtualenv

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

[Aleksey Avdeev]

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

Alexey Tourbin пишет:
> On Fri, Oct 26, 2007 at 10:56:13PM +0400, Peter V. Saveliev wrote:
> 
...
> 
> Если отбросить практическую причину (что программа сборки дополнительных
> модулей в двух экземлярах так никгода и не была даже частично
> реализована),

  Но _принципиальная_ возможность её реализации присутствовала. И это --
главное.

> то всё равно это никак нельзя по-нормальному сделать на
> уровне rpm-зависимостей.  То есть если /usr/bin/python висит на
> альтернативах, то эта альтернатива динамически переключает зависимости
> вида pythonX.Y(...) на pythonX.Z(...).  Я про это в свое время много спорил.

1. Можно напомнить суть споров? (Что-то не найду их в своём архиве...
Похоже не так ищу.)

2. Если не нравится /usr/bin/python на альтернативах, то может стоит
использовать вариант взаимоконфликтующих пакетов? (В смысле:
/usr/bin/pythonX и /usr/bin/pythonY спокойно уживаются вместе, но пакет
содержащий /usr/bin/python может быть только один.)

> 
> Можно будет оставить "чисто запасной" python2.4 с отключенным поиском
> питоновских зависимостей и без /usr/bin/python (только с
> /usr/bin/python2.4).  Может кто-нибудь этим займется ввиду суровой
> необходимости.
> 
> К тому же, схема зависимостей pythonX.Y(...) не дает возможность делать
> noarch пакеты, которые не должны зависеть от версии python'а.  По идее у
> таких пакетов должен быть Provides: python(...).  То как тогда ставить
> комплементарный Requires: python(...) или pythonX.Y(...) ?
> 
> То есть я полагаю что будет сделано так: будет всего один питон;
                                           ^^^^^^^^^^^^^^^^^^^^^^

  Мне активно не нравиться эта идея, т. к. на практике приведёт к тому,
что нужный для конкретного приложения питон (и само приложение) будет
развёрнут в /home/<user>... А это не тот стиль, который стоит
провоцировать (приходилось сталкиваться с таким, на предыдущей работе).

  Подход, когда приложение может потребовать нужную версию питона --
_мне_ нравится больше. Да, он сложнее в реализации. Но это то
направление (по интерпретируемым языкам) в котором нужно двигаться.

> будет сделан /usr/share/python/site-packages; все зависимости будут
> иметь вид python(...); компилированные пакеты будут дополнительно
> иметь зависимость на libpythonX.Y.so.M.N.  Вопрос с совместимостью
> версии байткода в noarch пакетах кажется мне непринципиальным -- если
> версия байткода в *.pyc не совпадает, питон просто будет загружать *.py.
> 

-- 

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


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

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

[Alexey Tourbin]

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

On Sun, Oct 28, 2007 at 03:56:47AM +0300, Aleksey Avdeev wrote:
> > Если отбросить практическую причину (что программа сборки дополнительных
> > модулей в двух экземлярах так никгода и не была даже частично
> > реализована),
> 
>   Но _принципиальная_ возможность её реализации присутствовала. И это --
> главное.

Принципиальная возможность есть всегда.
Другое дело, насколько это вписывается в дизайн репозитария.

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

Сумбурно отвечаю сразу на два вопроса.  Если хотим иметь два питона
в репозитарии, то никак не получается нормально сделать дефолтный
/usr/bin/python.  То есть нужно отказаться от /usr/bin/python ВООБЩЕ
и оставить только /usr/bin/pythonX.Y и /usr/bin/pythonX.Z.

Но отсутствие дефолтного питона явно не в интересах репозитария.

ПОЧЕМУ: сейчас дефолтный питон /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.

>   Мне активно не нравиться эта идея, т. к. на практике приведёт к тому,
> что нужный для конкретного приложения питон (и само приложение) будет
> развёрнут в /home/<user>... А это не тот стиль, который стоит
> провоцировать (приходилось сталкиваться с таким, на предыдущей работе).

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

>   Подход, когда приложение может потребовать нужную версию питона --
> _мне_ нравится больше. Да, он сложнее в реализации. Но это то
> направление (по интерпретируемым языкам) в котором нужно двигаться.

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

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

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

[Aleksey Avdeev]

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

Alexey Tourbin пишет:
> On Sun, Oct 28, 2007 at 03:56:47AM +0300, Aleksey Avdeev wrote:
> 
>>>Если отбросить практическую причину (что программа сборки дополнительных
>>>модулей в двух экземлярах так никгода и не была даже частично
>>>реализована),
>>
>>  Но _принципиальная_ возможность её реализации присутствовала. И это --
>>главное.
> 
> 
> Принципиальная возможность есть всегда.
> Другое дело, насколько это вписывается в дизайн репозитария.
> 
> 
>>>то всё равно это никак нельзя по-нормальному сделать на
>>>уровне rpm-зависимостей.  То есть если /usr/bin/python висит на
>>>альтернативах, то эта альтернатива динамически переключает зависимости
>>>вида pythonX.Y(...) на pythonX.Z(...).  Я про это в свое время много спорил.
>>
>>1. Можно напомнить суть споров? (Что-то не найду их в своём архиве...
>>Похоже не так ищу.)
>>
>>2. Если не нравится /usr/bin/python на альтернативах, то может стоит
>>использовать вариант взаимоконфликтующих пакетов? (В смысле:
>>/usr/bin/pythonX и /usr/bin/pythonY спокойно уживаются вместе, но пакет
>>содержащий /usr/bin/python может быть только один.)
> 
> 
> Сумбурно отвечаю сразу на два вопроса.  Если хотим иметь два питона
> в репозитарии, то никак не получается нормально сделать дефолтный
> /usr/bin/python.  То есть нужно отказаться от /usr/bin/python ВООБЩЕ
> и оставить только /usr/bin/pythonX.Y и /usr/bin/pythonX.Z.

  C этим пунктом согласен.

> 
> Но отсутствие дефолтного питона явно не в интересах репозитария.

  И с этим -- тоже.

> 
> ПОЧЕМУ: сейчас дефолтный питон /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>... А это не тот стиль, который стоит
>>провоцировать (приходилось сталкиваться с таким, на предыдущей работе).
> 
> 
> Я делаю системное решение.  То есть я исхожу из того, что все пакеты
> В РЕПОЗИТАРИИ должны будут работать/починиться под новый питон.
> Что там запускается из /home/user мне не особо интересно.  Если там есть
> что-то важное, то нужно это опакетить, и тогда придётся учитывать этот
> пакет в плане миграции на питон 2.5.

  Этот вариант идеален, но я не чую его жизнеспособности в условиях
ограниченности ресурсов. :-/

  При вашем варианте имеем следующие грабли:

1. Задержка на попадание нового питона в Сизиф, пока не будет
оттестировано всё, что будет сочтено "ядром питона"

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

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

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

> 
> 
>>  Подход, когда приложение может потребовать нужную версию питона --
>>_мне_ нравится больше. Да, он сложнее в реализации. Но это то
>>направление (по интерпретируемым языкам) в котором нужно двигаться.
> 
> 
> То что нам с вами нравится это иногда имеет мало отношения к реальности.
> То есть нам иногда нравятся противоречивые вещи, которые, строго говоря,
> по-нормальному никак нельзя совместить.

  Но это не значит, что таких путей искать не нужно.

-- 

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


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

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

[Vitaly Lipatov]

On 28 октября 2007, Aleksey Avdeev wrote:
...
>   При вашем варианте имеем следующие грабли:
>
> 1. Задержка на попадание нового питона в Сизиф, пока не будет
> оттестировано всё, что будет сочтено "ядром питона"
Собственно уже давно есть системы, в которых python 2.5 является 
основным, поэтому большого напряга в тестировании я не вижу.

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

>
> 3. Калуарность тестирования нового питона (т. к. помещать его
> в Сизиф, пока "ядром питона" не оттестировано/портировано --
> нельзя).
Кулуарность? Вообще я не очень понимаю наметившийся подход к 
Сизифу, как к стабильному и цельному репозиторию. Как бы нам не 
дойти до его стабильности путём устаревания компонент.

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

Вообще мне кажется, что слухи о новом 2.5, с которым всё 
сломается, сильно преувеличены. Если что и потребует небольших 
исправлений, так только на пользу знания языка мантейнером.

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

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

[Peter V. Saveliev]

В сообщении от Sunday 28 October 2007 10:38:22 Vitaly Lipatov написал(а):
<skip />
> >   Но это не значит, что таких путей искать не нужно.
>
> Ну как их найти?
<skip /> 

Поставить debian или gentoo.

Меня такое решение (в итоге был использован debian), по крайней мере, 
удовлетворило -- всё работает, проект переведён на совместимость с python 2.5 
за час.

Без помощи Сизифа.

-- 
Peter V. Saveliev

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

[Aleksey Avdeev]

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

Peter V. Saveliev пишет:
> В сообщении от Sunday 28 October 2007 10:38:22 Vitaly Lipatov написал(а):
> <skip />
> 
>>>  Но это не значит, что таких путей искать не нужно.
>>
>>Ну как их найти?
> 
> <skip /> 
> 
> Поставить debian или gentoo.
> 
> Меня такое решение (в итоге был использован debian), по крайней мере, 
> удовлетворило -- всё работает, проект переведён на совместимость с python 2.5 
> за час.
> 
> Без помощи Сизифа.
  ^^^^^^^^^^^^^^^^^^

  Именно такая тенденция мне и не нравится.

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

-- 

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


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

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

[Alexey Tourbin]

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

On Sun, Oct 28, 2007 at 12:41:33PM +0300, Aleksey Avdeev wrote:
> Peter V. Saveliev пишет:
> > В сообщении от Sunday 28 October 2007 10:38:22 Vitaly Lipatov написал(а):
> > <skip />
> > 
> >>>  Но это не значит, что таких путей искать не нужно.
> >>
> >>Ну как их найти?
> > 
> > <skip /> 
> > 
> > Поставить debian или gentoo.
> > 
> > Меня такое решение (в итоге был использован debian), по крайней мере, 
> > удовлетворило -- всё работает, проект переведён на совместимость с python 2.5 
> > за час.
> > 
> > Без помощи Сизифа.
>   ^^^^^^^^^^^^^^^^^^
> 
>   Именно такая тенденция мне и не нравится.
> 
>   Причём я вполне понимаю мотивы, которыми Пётр руководствовался. И не
> вижу альтернативных решений, в рамках Сизифа, которыми он мог бы
> воспользоваться... И считаю это опасным, с точки зрения разработки
> репозитария.

Здесь нет большой спицифики питона.  Как заметил Виталий Липатов,
любое нетривиальное обновление какого-либо другого может что-нибудь
сломать.  Это не повод плодить этот пакет в двух штуках, чтобы
разработчики имели "долгую" возможность проверить свой софт с той
и другой версией.  Тем более возводить это в принцип на уровне дизайна
репозитария.

Бороться с этим нужно другим способом -- транзакционными переходами.
То есть открывается транзакция на питон 2.5.  Пока все пакеты не
починятся под питон 2.5, транзакция прогрессирует.  Когда большая
часть пакетов починилась, транзакцию можно зафиксировать вручную.
Если же починились вообще все пакеты, тогда транзакция фиксируется
полуавтоматически (то есть вообще "без потерь").

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

Да, в сизиф отправляются "целостные" обкатанные решения.  То есть это
конструктор в смысле кубиков, а не "теста", которое можно замесить.
Проблемы разработчиков мне отчасти понятны.  На это у меня тоже есть
ответ -- отправляйте свой питоновский софт в сизиф.  Тогда он
автоматически включается в план транзакции по питону 2.5.
А если есть "непубликуемый" питоновский софт, тогда извините.

Так это происходит со всеми остальными пакетами.

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

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

[Aleksey Avdeev]

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

Vitaly Lipatov пишет:
> On 28 октября 2007, Aleksey Avdeev wrote:
> ...
> 
>>  При вашем варианте имеем следующие грабли:
>>
>>1. Задержка на попадание нового питона в Сизиф, пока не будет
>>оттестировано всё, что будет сочтено "ядром питона"
> 
> Собственно уже давно есть системы, в которых python 2.5 является 
> основным, поэтому большого напряга в тестировании я не вижу.

  Это не важно. Важно то, что альтернативную версию нельзя поставить в
VE/hasher, оставаясь в рамках Сизифа.

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

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

  Другой случай, когда альтернативный питон потребовался на промышленной
системе (и сроки стоят "вчера")... И если не будет этой возможности в
Сезифе (в виду особенностей структуры) -- не будет её и в дистрибутиве.

> 
> 
>>3. Калуарность тестирования нового питона (т. к. помещать его
>>в Сизиф, пока "ядром питона" не оттестировано/портировано --
>>нельзя).
> 
> Кулуарность? Вообще я не очень понимаю наметившийся подход к 
> Сизифу, как к стабильному и цельному репозиторию. Как бы нам не 
> дойти до его стабильности путём устаревания компонент.

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

  Хочет человек (и или нужно ему по каким либо причинам) разбираться с
не текущим питоном -- да флаг ему в руки. Да, при этом часть (все)
пакетов, ориентированную на текущий питон, придётся снести. Но это будет
_осознанный_ выбор. И главное, на мой взгляд -- обеспечить его возможность.

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

  Возможно мы имеем в виду разное. Уточню свою позицию:

1. Да, _основной_ питон (который /usr/bin/python по умолчанию) -- 1
(альтернативы с ним конфликтуют).

2. Да, никакой автоматики в выборе версии питона: если нужно собрать
что-то с альтернативой -- её нужно _явно_ указать в спеке.

3. Да, никакой обязаловки для мантейнера в плане поддержки пакетов
ориентированных на альтернативный питон.

4. Да, простейший спек для текущего питона.

  Если я чего-то не учёл -- прошу указать.

> 
> Вообще мне кажется, что слухи о новом 2.5, с которым всё 
> сломается, сильно преувеличены. Если что и потребует небольших 
> исправлений, так только на пользу знания языка мантейнером.

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

-- 

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


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

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

[Pavlov Konstantin]

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

On Sun, Oct 28, 2007 at 10:38:22AM +0300, Vitaly Lipatov wrote:
> Кулуарность? Вообще я не очень понимаю наметившийся подход к 
> Сизифу, как к стабильному и цельному репозиторию. Как бы нам не 
> дойти до его стабильности путём устаревания компонент.

Как будто сейчас это не так.

-- 
<wRAR> gvy: с президентом вас
<AMorozov> wRAR: третим будешь :-)
<AMorozov> ... после меня и Квасьневского :-)
<AMorozov> я поздравил лично Мишу, а Квасьневский - весь украинский народ :-)

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

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

[Alexey I. Froloff]

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

* 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 должен быть
каким-то особенным?  Только в силу своей кривости?

-- 
Regards,
Sir Raorn.

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

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

[Eugene Prokopiev]

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.

ссылку или ключевые слова для search.altlinux.ru?

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

разве этого недостаточно? ну давайте еще будем кривой софт выбрасывать 
из репозитария ;)

-- 
С уважением,
Прокопьев Евгений

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

[Alexey I. Froloff]

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

* Eugene Prokopiev <prokopiev@> [071028 13:36]:
> > У нас один perl, один tcl, один ruby.  Почему python должен быть
> > каким-то особенным?  Только в силу своей кривости?
> разве этого недостаточно? ну давайте еще будем кривой софт выбрасывать 
> из репозитария ;)
Либо он живёт в репозитарии по всем правилам в единственном
экземпляре, либо от него ничего не зависит.  Второй раз мне такой
жопы с обновлением не надо.

-- 
Regards,
Sir Raorn.

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

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

[Alexey Tourbin]

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

On Sun, Oct 28, 2007 at 01:31:50PM +0300, Eugene Prokopiev wrote:
> > У нас один perl, один tcl, один ruby.  Почему python должен быть
> > каким-то особенным?  Только в силу своей кривости?
> 
> разве этого недостаточно? ну давайте еще будем кривой софт выбрасывать 
> из репозитария ;)

Конечно.  The code must conform or die.

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

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

[Peter V. Saveliev]

В сообщении от Sunday 28 October 2007 17:12:36 Alexey Tourbin написал(а):
> On Sun, Oct 28, 2007 at 01:31:50PM +0300, Eugene Prokopiev wrote:
> > > У нас один perl, один tcl, один ruby.  Почему python должен быть
> > > каким-то особенным?  Только в силу своей кривости?
> >
> > разве этого недостаточно? ну давайте еще будем кривой софт выбрасывать
> > из репозитария ;)
>
> Конечно.  The code must conform or die.

Я что хочу сказать:

1. Репозитарий должен быть нужен. То есть, его существование само по себе ни 
для кого пользы не принесёт, если им пользоваться не будут.

2. Помимо репозитария Сизиф, есть ещё дистрибутивы и репозитарии. Ими 
пользуется 99,99% пользователей GNU/Linux по всему миру. То есть, даже 
востребованность Сизифа не означает мирового господства и тотальной 
монополии.

...

Как это влияет на софт.

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

С точки зрения участника проекта: проект не должен требовать менять религию, 
переходя для разработки на другой дистрибутив. То есть, если для разработки 
чего-либо мне нужно перейти на fedora, то это что-либо идёт фтопку, увы.

...

Как это соотносится с Сизифом.

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

Я долго ждал питона 2.5 в Сизифе, запакованного так же, как в Debian -- когда 
он ставится рядом, в /usr/lib/python2.5, когда дефолтной 
ссылки /usr/bin/python на него нет (она смотрит на 2.4), но когда можно уже 
начать тестирование, которое позволит выявить особенности новой среды (а на 
самом деле, уже давно не новой). Без этого тестирования я не могу быть уверен 
ни в чём, и коллеги, живущие на Fedora и python2.5, мне не помощники: им не 
запустить проект у себя. А когда в Сизифе появится этот питон, то я рано или 
поздно закончу тем, что вставлю-таки обратно-несовместимую конструкцию и 
создам проблемы пользователям python2.4

...

Всегда кто-то страдает, в данном случае страдают разработчики. В общем, ничего 
страшного: 0.01% пользователей линуха по всему миру не сделают погоды, если 
их проекты не смогут нормально разрабатываться в привычной им среде (Сизиф). 
Те, кому проект важен, будут его разрабатывать по любому, найдя средства (см. 
выше по треду), остальных не жалко.

А в Сизиф можно по-прежнему импортировать проекты, разработанные и 
оттестированные в более других средах.

-- 
Peter V. Saveliev

[devel] python vs gcc

[Alexey Tourbin]

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

On Sun, Oct 28, 2007 at 08:52:39PM +0400, Peter V. Saveliev wrote:
> (исключая gcc -- там полный набор), лишая разработчика универсальности среды. 
> Сизиф сейчас дружественен пользователю и мэйнтейнеру, но враждебен 
> разработчику.

Полный набор gcc тоже даёт проблемы.  Я сейчас хочу запаковать
статические библиотеки libatlas-devel-static с фортрановским кодом.
Соответствено, я добавил зависимость на libgfortran-devel-static,
но её недостаточно.  Она может быть удовлетворена таким образом,
что gcc всё равно не найдёт libfortran.a.

То есть если мы компилируем другим gcc то зависимость на libgfortran.a
разрешается по-другому, и gcc её не находит.

/usr/lib/gcc/i586-alt-linux/4.1.1/libgfortran.a
/usr/lib/gcc/i586-alt-linux/4.2.0/libgfortran.a

Эта зависимость двусмысленна, потому что ей можно приписать два варианта
разрешения, точнее, интерпретировать её несколькими способами:
1) Должна разрешаться в тот же пакет, с которым был собран
libatlas-devel-static, в данном случае libgfortran4.1-devel-static.
2) Должна динамически разрешаться в тот пакет, который комплементарен
текущей версии /usr/bin/gcc.
3) Должна динамически разрешаться в соответствии с версией
%set_gcc_version.
4) ...

То есть дублирование системных вещей ВСЕГДА привносит какую-то
неопределённость в семантику зависимостей.  Они перестают разрешаться
"как надо" и начинают разрешаться как попало.

С gcc эта проблема возникает редко и стоит не очень остро,
просто потому что gcc это такая вещь в себе и она имеет ограниченное
количество "двусмысленных выплесков" типа libgfortran-devel-static.
Но если речь идёт о базовом системном интерпретаторе, который служит
ОСНОВОЙ для порождения иерархии зависимостей, тогда эта проблема
возникает часто и стоит остро.

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

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 --]