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

[Aleksey Avdeev <solo@solin.spb.ru>]

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