Стоит ли компилировать python-скрипты?

Оцени время интерпретации (сравни со скоростью скомпиленной программы), может у твоей программы это не самое критичное, также как у портеджа, например.

установочный деб-пакет

У деба точно есть жирный плюс: как поставил пакетным манагером, так потом и снёс.

может у твоей программы это не самое критичное

Верно, в моей не критично, мелкая, не каких сложных вычислений, не чего такого.

как поставил пакетным манагером, так потом и снёс.

Ну да, логично.
А по поводу .svg?

так и свг тогда в зависимости... да и геймеры без свг ССЗБ

На современном железе компилирование актуально только для тяжёлых и системных программ.

Ты конечно в курсе PlayonLinux?

Вкурсе, собственно по этой причине и начал пилить свою, будет гораздо проще для домохозяек.

ЕМНИП, компиляция пистоньих скриптов влияет только на время загрузки, не затрагивая производительность. Не нужно, короче.

Не знаю, какие бинарники ты собрался делать из питоньих скриптов.

1. Не компилируй. После первого запуска скрипта интерпретатором будет создана его скомпилированная в байткод версия и записана в .pyc-файл рядом с исходным скриптом. При последующих запусках скрипта будет использована его компилированная версия (за исключением тех случаев, когда в исходном скрипте были сделаны изменения после создания .pyc-файла, тогда создается новая байткомпилированная версия).
Предварительная компиляция даёт то очевидное преимущество, что исключается парсинг исходного кода, построение АСТ и собственно сама компиляция. В основном это экономия процессорного времени, другой вопрос каких размеров исходный код, для мелких задач получится скорее всего экономия на спичках.

2. Для распространения, наверное, лучше что-то универсальное, вроде http://pypi.python.org/, зачем привязываться к отдельным дистрам?

1) т.к. питон все равно компилирует в байт-код при выполнении, замерь время компиляции *.py->*.pyc и от этого пляши

2) если делать деб-пакет, неплохо было бы сделать rpm-пакет, pkgbuild, ebuild, тарбол для слакваршиков и т.д. Понятно, что сборка оных должна рулиться скриптами, которых дергает система сборки (хотя бы банальный makefile)

3) если делаешь пакет, на шаге 2, просто прописываешь ему в зависимости libsvg или как там она называется. Нужность SVG определяется наличием у тебя масштабируемого контента. Необходимости в котором для проги, создающей wine-prefix я лично не вижу. Виджеты должен масштабировать gui-toolkit

что ты называешь компиляцией питона?

питон все равно компилирует в байт-код при выполнении

делается это один раз при запуске либо при установке пакета.

python /usr/share/doc/python2.6/examples/Tools/freeze/freeze.py myhelloworld.py
make
./myhelloworld

Например.

Куда ж проще.
Делай не компилирующийся скрипт.

под компиляцией имел ввиду «скомпилировать текущий файл» в geany, после этой процедуру появляется скомпиленый .pyc, еще есть компиляция в бинарник: http://satels.blogspot.com/2010/03/python-code-linux-ubuntu.html

*процедуры

ну и нафиг это нужно кроме как сокрыть исходники? Байт-код питонозависим, что работает с твоим интерпретатором не заведётся на другом. Это помимо того что пути зависят от версии питона. В новых, например, оно в __pycache__ живёт.

1. Отдавай скриптом. Не отбирай преимущества скриптовых языков. Много программ распространяются как есть (gmusicbrowser тот же).

2. Тарболл подойдет многим. Каждый сможет создать себе пакет,если хочет держать систему архичистой. Кто же не умеет - вполне запустит скрипт. Итого: и ты не выполняешь лишнюю работу, и остальным по потребностям.

3. Опционально. Определяй наличие.

ясно