From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 11 Feb 2004 15:50:23 +0600 From: Alexey Morozov To: ALT Devel discussion list Subject: Re: [devel] Python Modules Policy: Message-ID: <20040211095023.GV13525@pyro.hopawar.private.net> 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> <4028FDF6.3070802@l14.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YqKeQn+qkMVHQmbT" Content-Disposition: inline In-Reply-To: <4028FDF6.3070802@l14.ru> User-Agent: Mutt/1.4i 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: Wed, 11 Feb 2004 09:50:26 -0000 Archived-At: List-Archive: List-Post: --YqKeQn+qkMVHQmbT Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Tue, Feb 10, 2004 at 06:51:18PM +0300, Алексей Любимов wrote: > > >Не вопрос. Мы с Андреем уже договорились (в джаббере) до того, что > > > >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 того питона, для которого производилась сборка. > Это понятно. ldv@ уже предложил решение, которое, вроде бы, не хуже по последствиям, но автоматизируется. Прокомментируйте его, пожалуйста. > >Предлагается подумать над следующими двумя полиси: > >6. Программы на python, не зависящие от конкретной версии питона > > (epydoc, python-doc-tools), собираются _без_ байткода и, > > соответственно, без привязки к точной версии питона, используется > > #!/usr/bin/env python ... > А где же они лежать будут? по логике все равно в python?.?/site-packages/ Нет. Питоньи скрипты (н-р, python-doc-tools) лежат не там. epydoc тоже лежит не там, вроде бы. Если нужно подумать над "версионно-независимом" каталоге для питона, его можно организовать, насколько я понимаю. > По моему, это излишнее усложнение. Поддерживается один питон, так и > пусть поддерживается. > Наоборот скорее от сорцов надо избавлятся (только без размножения > пакетов). Без разможения пакетов - плохо, по-моему. Я сейчас периодически сам заглядываю в твистедовые потроха, чтобы понять, что же имелось ввиду в доке. > >7. Программы, имеющие такую привязку (н-р, идущие вместе с конкретной > > версией питона) иcпользуют #!/usr/bin/env python ... > > и могут таскать за собой байткод. > В скриптах? и вы согласны переписывать все скрипты в модуле при переходе > версий??? Если эти _скрипты_ завязаны на данную версию питона: да, согласен. Но, мой опыт (сборки twisted) показывает, что достаточно внятно разделить: вот этот пакет - модул{ь,и}, он[и] привязан[ы] к версии питона, а вот это - скрипты [из /usr/bin], которые одинаково хорошо работают как с твистедом, собранным под 2.2, так и с твистедом, собранным под 2.3 > >8. Некоторое время назад Андрей предлагал в "боевых" пакетах таскать > > только байткод, а .py заворачивать в отдельные пакеты "для > > интересующихся" (по моему разумению, по схеме, напоминающей то, что > > делает Алекс Отт для емакса, хотя _это мои предположения_) > И наплодить еще дубликатов-пакетов пачку. У Андрея были практические соображения, почему в боевую версию НЕ надо пихать сорцы. С другой стороны, мой небольшой практический опыт показывает, что сорцы _иногда_ нужны. > У меня вот зреет какое то общее средство под кодовым названием stripper. ... > Также можно поставить правила по умолчанию и они будут срабатывать при > установке пакетов сами. Это никак не упихивается в рамки distutils? > > Незрело, конечно, но по моему, вполне может получится... Показывайте. --YqKeQn+qkMVHQmbT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAKfrfX5DZdJn19V0RAmOCAJ4seMGyX0bbaWYljiym2JFVl0gewwCgjCSR BYHQp+/jIR29+Sa2lmwnGz4= =kuMh -----END PGP SIGNATURE----- --YqKeQn+qkMVHQmbT--