[Sarlug] StreamVK

Evgeny Sinelnikov sin на altlinux.ru
Вс Июл 22 14:20:39 MSK 2012


22 июля 2012 г., 13:47 пользователь Vladislav Slepukhin
<slp.vld на gmail.com> написал:
>> Это было что-то странное сказано - понять невозможно, что имелось в
>> виду. PyObject, например  - это такая структура в API для CPython:
>> http://ru.wikipedia.org/wiki/CPython
>
> Имелось в виду, как я понял PyGObject. Посмотрю, что удобнее.

Есть неразрывная программная связка: GLib -> GTK++
Есть такая же неразрывная пара связок для питона:

$ rpm --test -e python-module-pygobject 2>&1 | grep gtk
        python2.6(gobject)   нужен для python-module-pygtk-2.24.0-alt3
        python2.6(pygtk)   нужен для simple-ccsm-0.8.4-alt3.M60P.1
        python2.6(pygtk)   нужен для gimp-2.8.0-alt0.M60P.1
        python2.6(pygtk)   нужен для ccsm-0.8.4-alt2

Они не могут быть разделены и не могут быть одно удобнее другого - это
целостный набор связок.


>>
>> По сборке дистрибутивных пакетов в блоге устаревшая команда указана, Нужно
>> так
>> $ python setup.py bdist_rpm
>
> То бишь python-install заворачивается в rpm?

Я не знаю что такое python-install. Есть в питоне модуль sеtup,
который предназначен для сборки. В проектах, которые его используют,
создают файл setup.py, который представляет собой описатель и код в
одном флаконе.

$ ls
build  dist  doc  epydoc  LICENSE.txt  Makefile  man  MANIFEST
PKG-INFO  README.txt  scripts  setup.py

$ python setup.py --help-commands
Standard commands:
  build            build everything needed to install
  build_py         "build" pure Python modules (copy to build directory)
  build_ext        build C/C++ extensions (compile/link to build directory)
  build_clib       build C/C++ libraries used by Python extensions
  build_scripts    "build" scripts (copy and fixup #! line)
  clean            clean up temporary files from 'build' command
  install          install everything from build directory
  install_lib      install all Python modules (extensions and pure Python)
  install_headers  install C/C++ header files
  install_scripts  install scripts (Python or otherwise)
  install_data     install data files
  sdist            create a source distribution (tarball, zip file, etc.)
  register         register the distribution with the Python package index
  bdist            create a built (binary) distribution
  bdist_dumb       create a "dumb" built distribution
  bdist_rpm        create an RPM distribution
  bdist_altrpm     create an ALTLinux RPM distribution
  bdist_altrpm     create an ALTLinux RPM distribution
  bdist_wininst    create an executable installer for MS Windows
  upload           upload binary package to PyPI

usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help


>>
>> Есть ещё bdist_wininst, но я его не проверял... Вообще, для пакетов
>> важны зависимости. Правда их отсутствие иногда лучше, чем битые. Если
>> понимаешь, что нужно доставить, то всегда можно доставить. С другой
>> стороны вопрос состоит в том, как ты хочешь распространять. Заданную
>> сборку для своего дистрибутива или набор сборок под разные.
>>
>> Если под разные то под какие? Разные релизы федоры или убунты - уже,
>> по сути, разные дистрибутивы, для которых требуются разные спек-файлы
>> и одного автогенерируемого не хватит.
>
> Хотелось бы мейнтейнить пакет под Windows и под Ubuntu, ибо в одиночку
> большее - уже очень сложно вытянуть.

Что значит мейнтейнить? Держать у себя на сайте фалы для закачки? Ok,
тогда вопрос. Под какую версию убунты? Потому что под разные версии
могут потребоваться быть разные пакеты. Где-то прокатит один и тот же
пакет, где-то - нет. А ещё желательно, чтобы оно обновлялось при
обновлении системы. Для этого желательно не файл, а репозиторий
предоставить.

Для винды всё то же самое, только там принято всё сносить и ставить
заново при обновлении системы. Хотя вопрос о версии всё равно будет -
32 или 64-битная. А то ещё и XP или Семёрка... А также версии нужных
библиотек для бинарных связок, которые прибиты к звданной версии
питона.

Вот список узловых точек:
Операционная система -> Архитектура -> Версия питона -> Версия связок

При этом в Linux чётко предполагается Версия питона и Версия связок, в
соответствии с версией дистрибутива. А под Windows это неизвестно -
как решишь, так и будет. Правда придётся тащить питон чуть ли не у
себя в дистрибутиве, причём вместе со связками... И так для каждого
приложения... Но у тебя-то он одно. ;)

И у всех по одному обычно ;)
Вот и распухают у нас системы до неимоверных размеров....


-- 
Sin (Sinelnikov Evgeny)
Etersoft


Подробная информация о списке рассылки Sarlug