Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
Беспроводные выключатели nooLite купить дешевый 
компьютер родом из Dhgate.com
  • Фото розы
  • Материалы журнала Фото Горький. Отзывы и фото туристов
  • fotografii-cvetov.ru

Lines Club

Ищем достойных соперников.

Библиотека сайта или "Мой Linux Documentation Project"

Архитектура системы управления пакетами в Python

Глава 14 из 1 тома книги "Архитектура приложений с открытым исходным кодом".

Оригинал: Python Packaging
Автор: Tarek Ziade
Дата публикации: 7 Июня 2012 г.
Перевод: А.Панин
Дата публикации перевода: 3 апреля 2013 г.

Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.


14.1 Введение

При разговоре о системах установки приложений обычно упоминают о двух подходах. Первый подход, характерный для Windows и Mac OS X, заключается в распространении самодостаточных пакетов приложений, процесс установки которых не должен зависеть от внешних факторов. Эта философия упрощает процесс управления приложениями: каждое приложение имеет свое отдельное "окружение" и его установка или удаление не влияет на другие части ОС. Если приложению для работы требуется нестандартная библиотека, эта библиотека включается в состав пакета для распространения приложения.

Второй подход, характерный для систем на основе ядра Linux, рассматривает программное обеспечение как набор небольших программных компонентов, называемых пакетами. Библиотеки добавляются в пакеты, причем любой пакет с библиотекой может зависеть от других пакетов. Процесс установки приложения может включать в себя процесс поиска и установки определенных версий множества других библиотек. Эти зависимости обычно доставляются из стандартного репозитория, содержащего тысячи пакетов. Данная философия обуславливает использование в дистрибутивах Linux таких сложных систем управления пакетами, как dpkg и RPM для отслеживания зависимостей и предотвращения установки двух приложений, использующих несовместимые версии одной и той же библиотеки.

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

Но модульность системы воспринимается как препятствие некоторыми разработчиками, так как они не могут контролировать работу своих приложений и их зависимостей. Для них было бы проще создать отдельный программный пакет для того, чтобы быть уверенными в том, что приложение будет работать в стабильном программном окружении, не попадая в "ад зависимостей" во время обновления системы.

Самодостаточные пакеты приложений также упрощают деятельность разработчика в том случае, когда он желает поддерживать несколько операционных систем. Некоторые проекты выпускаются в виде переносимых приложений, в которых исключено любое взаимодействие с файлами операционной системы, а работа осуществляется только с директорией приложения, даже в случае сохранения файлов журналов.

Система управления пакетами в Python разрабатывалась с использованием второго подхода - использовалось множество зависимостей для каждого пакета, а также система должна была быть так дружелюбна к разработчику, администратору и пользователю, как это возможно. К сожалению, она имела (и имеет) различные дефекты, обуславливающие и приводящие к разного рода проблемам: использованию неинтуитивных схем записи версий, наличию необрабатываемых файлов с данными, сложностям с повторной упаковкой и другим. Три года назад я и группа разработчиков Python решили повторно разработать эту систему для устранения вышеописанных проблем. Мы называем нашу группу Товариществом Разработчиков Системы Пакетов, а в данной главе будут описаны недостатки, которые мы пытались исправить, а также предложенные нами решения.

Терминология

При разговоре о пакете в Python имеется в виду директория с файлами исходного кода Python. Файлы исходного кода Python называются модулями. Такое описание приводит к непониманию при использовании слова "пакет", так как пакетом в ряде систем также называют релиз проекта.

Разработчики Python сами иногда путаются при разговоре об этом. Единственным путем преодоления этой двусмысленности является использование термина "пакет Python" при разговоре о директории, содержащей модули Python. Термин "релиз" используется для описания одной версии проекта, а термин "дистрибутив" - для бинарных файлов или исходных кодов релиза, например, в форме файла архива tar или zip.


Далее: 14.2. Трудности разработчиков Python


Эта статья еще не оценивалась
Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.

Комментарии отсутствуют