* [devel] Q: что делать с *.py vs *.py[oc]? (was: solfege-1.4.1-alt0.9.src.rpm)
@ 2002-01-31 15:11 ` Michael Shigorin
2002-02-01 9:51 ` [devel] " Mikhail Zabaluev
0 siblings, 1 reply; 2+ messages in thread
From: Michael Shigorin @ 2002-01-31 15:11 UTC (permalink / raw)
To: Stanislav Ievlev; +Cc: devel
[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]
Здравствуйте.
Имеет место вопрос по политике упаковки precompiled-скриптов и их
исходников. Так как проблема явно не ограничивается одним
пакетом, просьба прокомментировать.
On Thu, Jan 31, 2002 at 02:38:58PM +0300, Stanislav Ievlev wrote:
> >>>.py специально потеряли. А вот насчет .pyo -- оптимизацию Юрий
> >>>только сегодня туда и вкрутил ("нова возможность") ;-)
> >>Не понял, чем они помешали ... какое-то скрытие исходников прямо.
> >Да нет -- или i586 тоже является сокрытием исходников? ;)
> >Юрий заметил, что .py необходимыми не являются, а вот место на
> >диске занимают -- и поправил спек. Я счел это резонным.
> Это понятно, но все-равно не есть хорошо.
> А если человек собрал свою версию питона и ему по-хорошему надо
> перекомпилировать байт код?
rpm --rebuild (насколько я понимаю текущую политику, человек с
"а если" подозревается в осознании своих действий и способности
перебрать affected части системы).
> Что если что-то случиться с питоном (как уже неоднократно было) при
> очередном обновлении и он не сможет читать байт-код, выдавая "bad
> marshal data"?
В сизифе или где? Опять же, вопрос скорее policy. Посему даю
копию в devel и с надеждой жду ответа MhZ ;-)
На самом деле, по-моему, это не что иное, как резон для Requires
на конкретную версию питона, с которой производилась
прекомпиляция.
> Если есть *.py файлы, то человек сможет по крайней мере исправить
> ситуацию, а если нет?!!!
А как он собирается исправлять ситуацию по принадлежащим некоему
пакету файлам без прав рута?
Кстати, а что сделает питон, если увидит лежащие рядом .py и
более старый .py[oc], а прав на запись в каталог/файл не будет?)
И если будет иметь место перекомпиляция (рутом), то по крайней
мере rpm -Va будет существенно замусорен, в отличие от
rpm --rebuild *_на_питоне.
> Избыточная оптимизация скорее вредна, чем избыточна. Когда речь идет о
> скриптовых языках, то во избежание проблем скрипты должны быть.
Опять же -- насколько я понимаю, налицо специфика. Вот и давайте
решим, что с ней делать. По крайней мере в Вашем варианте,
Станислав, имеем конфликт потенциально динамической природы
скриптов (точнее, прекомпиляции) и статической сути той же базы
rpm (не говоря о r/o натуре /usr).
> Если уж очень хотите прооптимизировать пакет, то гораздо правильнее
> разбить его на несколько подпакетов, например
> solfedge-common
> solfedge-precompiled
> solfedge-py
Вот примерно так и думали -- выделить .py ...куда? В -devel --
неправильно, для разработчика, скорее всего, все исходники, .po и
Makefile потребуются. В -py разве что? Но тогда имеет смысл
пройтись подобным образом по остальным питоньим пакетам.
И имеем или существенное увеличение количества бинарных пакетов
(минимум удвоение по питон-базированным), или нерациональное
использование дискового пространства в большинстве случаев.
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ http://visa.chem.univ.kiev.ua/~mike/
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* [devel] Re: Q: что делать с *.py vs *.py[oc]? (was: solfege-1.4.1-alt0.9.src.rpm)
2002-01-31 15:11 ` [devel] Q: что делать с *.py vs *.py[oc]? (was: solfege-1.4.1-alt0.9.src.rpm) Michael Shigorin
@ 2002-02-01 9:51 ` Mikhail Zabaluev
0 siblings, 0 replies; 2+ messages in thread
From: Mikhail Zabaluev @ 2002-02-01 9:51 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 4149 bytes --]
Hello Michael,
On Thu, Jan 31, 2002 at 05:11:24PM +0200, Michael Shigorin wrote:
>
> Здравствуйте.
> Имеет место вопрос по политике упаковки precompiled-скриптов и их
> исходников. Так как проблема явно не ограничивается одним
> пакетом, просьба прокомментировать.
>
> On Thu, Jan 31, 2002 at 02:38:58PM +0300, Stanislav Ievlev wrote:
> > >>>.py специально потеряли. А вот насчет .pyo -- оптимизацию Юрий
> > >>>только сегодня туда и вкрутил ("нова возможность") ;-)
> > >>Не понял, чем они помешали ... какое-то скрытие исходников прямо.
> > >Да нет -- или i586 тоже является сокрытием исходников? ;)
> > >Юрий заметил, что .py необходимыми не являются, а вот место на
> > >диске занимают -- и поправил спек. Я счел это резонным.
> > Это понятно, но все-равно не есть хорошо.
> > А если человек собрал свою версию питона и ему по-хорошему надо
> > перекомпилировать байт код?
> rpm --rebuild (насколько я понимаю текущую политику, человек с
> "а если" подозревается в осознании своих действий и способности
> перебрать affected части системы).
>
> > Что если что-то случиться с питоном (как уже неоднократно было) при
> > очередном обновлении и он не сможет читать байт-код, выдавая "bad
> > marshal data"?
> В сизифе или где? Опять же, вопрос скорее policy. Посему даю
> копию в devel и с надеждой жду ответа MhZ ;-)
>
> На самом деле, по-моему, это не что иное, как резон для Requires
> на конкретную версию питона, с которой производилась
> прекомпиляция.
>
> > Если есть *.py файлы, то человек сможет по крайней мере исправить
> > ситуацию, а если нет?!!!
> А как он собирается исправлять ситуацию по принадлежащим некоему
> пакету файлам без прав рута?
>
> Кстати, а что сделает питон, если увидит лежащие рядом .py и
> более старый .py[oc], а прав на запись в каталог/файл не будет?)
>
> И если будет иметь место перекомпиляция (рутом), то по крайней
> мере rpm -Va будет существенно замусорен, в отличие от
> rpm --rebuild *_на_питоне.
>
> > Избыточная оптимизация скорее вредна, чем избыточна. Когда речь идет о
> > скриптовых языках, то во избежание проблем скрипты должны быть.
> Опять же -- насколько я понимаю, налицо специфика. Вот и давайте
> решим, что с ней делать. По крайней мере в Вашем варианте,
> Станислав, имеем конфликт потенциально динамической природы
> скриптов (точнее, прекомпиляции) и статической сути той же базы
> rpm (не говоря о r/o натуре /usr).
>
> > Если уж очень хотите прооптимизировать пакет, то гораздо правильнее
> > разбить его на несколько подпакетов, например
> > solfedge-common
> > solfedge-precompiled
> > solfedge-py
> Вот примерно так и думали -- выделить .py ...куда? В -devel --
> неправильно, для разработчика, скорее всего, все исходники, .po и
> Makefile потребуются. В -py разве что? Но тогда имеет смысл
> пройтись подобным образом по остальным питоньим пакетам.
>
> И имеем или существенное увеличение количества бинарных пакетов
> (минимум удвоение по питон-базированным), или нерациональное
> использование дискового пространства в большинстве случаев.
В параграфе 6.1.2 tutorial'а по Python всё очень чётко написано.
Коротко:
- .pyo используются с опцией -O, .pyc в отсутствие этой опции;
- невозможность создать или обновить .pyc/.pyo при наличии .py
не является ошибкой;
- отсутствие .py при наличии .pyc/.pyo не является ошибкой.
То есть .py можно и выделить в необязательный добавочный пакет,
как это сделано в emacs-el. Но все остальные python-related файлы
и то, что они используют, должны быть в основном пакете.
Нельзя ставить в зависимость работы скриптов опцию -O.
Нужно ещё учитывать, что .py понадобятся при отладке.
Вообще, если посмотреть по размерам, получается экономия примерно на
треть, не учитывая прочих файлов. Намного меньше, чем даёт
выделение статических библиотек в devel-static. Стоит ли
париться?
Оставить, скажем, только .pyo можно тогда, когда модули используются
строго с опцией -O и только для исполнения. В инсталляторе этот номер
пройдёт на ура.
--
Stay tuned,
MhZ JID: mookid@jabber.org
___________
The Constitution may not be perfect, but it's a lot better than what we've got!
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2002-02-01 9:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-01-31 15:11 ` [devel] Q: что делать с *.py vs *.py[oc]? (was: solfege-1.4.1-alt0.9.src.rpm) Michael Shigorin
2002-02-01 9:51 ` [devel] " Mikhail Zabaluev
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git