Библиотека сайта rus-linux.net
Архитектура системы управления пакетами в Python
Глава 14 из 1 тома книги "Архитектура приложений с открытым исходным кодом".
Оригинал: Python Packaging
Автор: Tarek Ziade
Дата публикации: 7 Июня 2012 г.
Перевод: А.Панин
Дата публикации перевода: 3 апреля 2013 г.
Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.
14.6. Выученные уроки
14.6.1. О стандартах PEP
Изменение архитектуры таких обширных и сложных проектов, как система управления пакетами Python, должно производиться аккуратно путем изменения стандартов PEP. А само изменение или добавление нового стандарта PEP, по моему опыту, занимает около года.
Одной ошибкой, которую совершило сообщество является разработка инструментов, исправляющих некоторые недоработки путем расширения метаданных и изменения хода установки приложений Python, без попытки изменения затронутых стандартов PEP.
Другими словами, в зависимости от используемого вами инструмента, Distutils из стандартной библиотеки или Setuptools, приложения устанавливались по-разному. Проблемы были преодолены одной частью сообщества, использующей новые инструменты, но для всего остального мира проблем только добавилось. Лица, ответственные за создание пакетов для операционных систем, столкнулись с несколькими стандартами Python: официальным документированным стандартом и фактически используемым стандартом, установленным разработчиками пакета Setuptools.
Но между тем, команда разработчиков пакета Setuptools имела возможность проведения экспериментов над огромной аудиторией (всем сообществом), быстро внедряя инновации, поэтому информация от пользователей была бесценна. У нас же была возможность разрабатывать новые стандарты PEP с большей уверенностью в том, что будет работать, а что не будет и, возможно, по-другому этого сделать бы и не удалось. Таким образом, процесс заключался в наблюдении за тем, какие инновации предлагались сторонними инструментами и решали ли эти инновации проблемы достаточно хорошо, чтобы инициировать изменение стандарта PEP.
14.6.2. Пакет, добавленный в стандартную библиотеку, находится одной ногой в могиле
Я перефразировал Гвидо ван Россума в названии раздела, но существует один аспект философии "batteries-included" Python, который значительно повлиял на нашу работу.
Пакет Distutils является частью стандартной библиотеки и пакет Distutils2 также скоро станет ее частью. Пакет, являющийся частью стандартной библиотеки, очень сложно развивать. Конечно же, существуют процессы по удалению устаревшего кода, в ходе которых вы можете удалить или изменить часть API после 2 подверсий Python. Но как только происходит публикация API, данный интерфейс остается неизменным в течении многих лет.
Таким образом, любое сделанное вами изменение в пакете стандартной библиотеки, не являющееся исправлением ошибки, является потенциальным нарушением целостности экосистемы. Поэтому тогда, когда вы делаете важные изменения, вы должны создавать новый пакет.
Я убедился в этом на собственном опыте, когда в процессе работы над пакетом Distutils мне пришлось убрать все изменения, сделанные мною более чем за год, и создать пакет Distutils2. В будущем, если наши стандарты снова изменятся кардинальным образом, велика вероятность того, что мы с самого начала начнем работу над отдельным проектом Distutils3, конечно же, если в стандартной библиотеке не появится другой установщик.
14.6.3. Обратная совместимость
Изменение принципа работы системы управления пакетами в Python является очень долгим процессом: экосистема Python содержит множество проектов, базирующихся на устаревших инструментах управления пакетами, поэтому сопротивление изменениям будет весьма значительным. (Достижение соглашения по вопросам, описанным в данной главе книги, заняло несколько лет вместо нескольких месяцев, как я ожидал сначала.) Как и в случае с Python 3, пройдут годы перед тем, как все проекты перейдут на использование нового стандарта.
Именно поэтому все разрабатываемые нами программные продукты должны поддерживать обратную совместимость с используемыми ранее инструментами, установками и стандартами, что делает реализацию пакета Distutils2 еще более сложной.
Например, если проект, использующий новые стандарты, зависит от другого проекта, который их пока еще не использует, мы не можем прерывать процесс установки, сообщая пользователю о том, что пакет, от которого зависит проект, использует неизвестный формат!
Стоит отметить, что реализация механизма INSTALL-DB содержит код для совместимости, позволяющий работать с проектами, установленными с помощью оригинального пакета Distutils, Pip, Distribute или Setuptools. Distutils2 также поддерживает возможность установки проектов, созданных с использованием оригинального пакета Distutils, конвертируя метаданные в ходе установки.
Далее: 14.7. Справочные материалы и вклад сообщества