From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <4028FDF6.3070802@l14.ru> From: =?KOI8-R?Q?=E1=CC=C5=CB=D3=C5=CA_=EC=C0=C2=C9=CD=CF=D7?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20031103 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Devel discussion list Subject: Re: [devel] Python Modules Policy: References: <87znbsh12p.fsf@pc349.belcaf.minsk.by> <200402100025.27343.cray@neural.ru> <40280A53.7090301@l14.ru> <200402100301.33551.cray@neural.ru> <40288B88.2060303@l14.ru> <20040210080400.GG13525@pyro.hopawar.private.net> <4028A20E.2030302@l14.ru> <20040210101551.GO13525@pyro.hopawar.private.net> In-Reply-To: <20040210101551.GO13525@pyro.hopawar.private.net> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2004 15:54:56 -0000 X-List-Received-Date: Tue, 10 Feb 2004 15:54:56 -0000 X-List-Received-Date: Tue, 10 Feb 2004 15:54:56 -0000 Date: Tue, 10 Feb 2004 15:54:56 -0000 X-Original-Date: Tue, 10 Feb 2004 18:51:18 +0300 X-List-Received-Date: Tue, 10 Feb 2004 15:54:56 -0000 Message-ID: <20040210155456.sxX23z5dvAe-8hn9i8c-Qfy1wVSRz6fKGtGSuuVGaqA@z> Archived-At: List-Archive: List-Post: >Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что > >1. Он проставляет Obsoletes: pythonN в python{N+1} или делает > аналогичные изменения, о точном решении будет сообщено > дополнительно ориентировочно в конце недели. >2. _Одновременная_ сборка пакетов под разные версии питона является > на данный момент ненужной ввиду своей трудоемкости. > реально это означает, что поддержка python22 отменяется. Или, проще говоря, на зоп* в сизифе и все, что посложнее "hello world" можно забить. >3. Андрей думает над целесообразностью сборки пакетов вида > python-ModuleName из исходника вида python-ModuleName > Если будет строго выполнен пункт 2, то это имхо лишнее... Уж если у кого дойдут руки, то можно делать пакеты python22-ModuleName то есть схема пакет и compat-пакет, а не ПакетВерсия1 и ПакетВерсия2 >5. В полиси для питоньих модулей вносится обязательный > Requires: python = %, где % совпадает с > %__python_version того питона, для которого производилась сборка. > Это понятно. >Предлагается подумать над следующими двумя полиси: >6. Программы на python, не зависящие от конкретной версии питона > (epydoc, python-doc-tools), собираются _без_ байткода и, > соответственно, без привязки к точной версии питона, используется > #!/usr/bin/env python ... > А где же они лежать будут? по логике все равно в python?.?/site-packages/ По моему, это излишнее усложнение. Поддерживается один питон, так и пусть поддерживается. Наоборот скорее от сорцов надо избавлятся (только без размножения пакетов). >7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной > версией питона) иcпользуют #!/usr/bin/env python ... > и могут таскать за собой байткод. > В скриптах? и вы согласны переписывать все скрипты в модуле при переходе версий??? >8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать > только байткод, а .py заворачивать в отдельные пакеты "для > интересующихся" (по моему разумению, по схеме, напоминающей то, что > делает Алекс Отт для емакса, хотя _это мои предположения_) > И наплодить еще дубликатов-пакетов пачку. У меня вот зреет какое то общее средство под кодовым названием stripper. В пакеты кладутся схемы файлов в виде регэкспов. Также пишуться глобальные регэкспы типа __nodoc__ = /usr/share/doc/.* __noman__ = /usr/share/man/.* /.* __nopy_source__ = *.py __nopy_pyc__ = *.pyc В любой момент, включая установку пакета, можно вызвать stripper пакет(ы) и он обрежет по правилам файлы и перенесет их в архив или вернет обратно. Также можно поставить правила по умолчанию и они будут срабатывать при установке пакетов сами. Незрело, конечно, но по моему, вполне может получится...