[devel] Переходное полиси для для питона
Aleksey Avdeev
=?iso-8859-1?q?solo_=CE=C1_solin=2Espb=2Eru?=
Вс Окт 28 13:27:59 MSK 2007
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, с которым всё
> сломается, сильно преувеличены. Если что и потребует небольших
> исправлений, так только на пользу знания языка мантейнером.
Возможно. Но случаи бывают разные... Всё сразу не предусмотришь -- а
значит -- нужны пути для манёвров. И пусть лучше они будут штатными:
тогда возможность переводить частные велосипеды в дистрибутивное русло
упроститься (и сама необходимость их наличия может сократиться).
--
С уважением. Алексей.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : signature.asc
Тип : application/pgp-signature
Размер : 548 байтов
Описание: OpenPGP digital signature
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20071028/b9cb50ce/attachment-0002.bin>
Подробная информация о списке рассылки Devel