Python — один из самых популярных языков программирования в мире, используемый для самых разных задач: от веб-разработки до науки о данных. Однако один из любопытных аспектов его экосистемы — это то, что функционал упаковки (package management) никогда не был частью ядра языка и развивался отдельно. Почему так сложилось и к каким последствиям это привело? Рассмотрим этот вопрос детально, опираясь на интервью с одним из ведущих разработчиков ядра Python, Брлеттом Кэнноном, а также на исторический контекст и текущее состояние дел вокруг управления пакетами в Python. Изначально, когда Python набирал популярность, сфера управления пакетами и распространения библиотек была достаточно слабо развита и не являлась приоритетом для команды разработчиков ядра. Гвидо ван Россум, создатель языка, и большая часть основных разработчиков не уделяли этому направлению значительного внимания.
С момента, когда появилось потребность в системах упаковки, они оставались в стороне, потому что не было особого интереса заниматься этими вопросами. Это действительно сводится к тому, что для ключевых разработчиков Python тема управления пакетами просто «не была их делом». В итоге функционал, связанный с упаковкой, оказался в руках сообщества. Почему это случилось именно так? Одной из главных причин стало то, что для попадания в ядро Python требуются навыки и опыт работы с самим интерпретатором, стандартной библиотекой и элементами низкоуровневой реализации языка. Знание нюансов систем распространения библиотек и пакетов не давало дополнительных преимуществ для становления ключевым разработчиком.
То есть область управления пакетами развивалась в своем собственном направлении, и энтузиасты из сообщества начинали создавать свои решения на основе своих нужд и опыта. Самая ранняя попытка стандартизировать процесс распространения пакетов — модуль distutils — была ориентирована на упрощение сборки и установки модулей, однако в целом была достаточно слабой и неудобной в использовании. Она являлась частью стандартной библиотеки, но не получила широкого признания, и с течением времени стала восприниматься как устаревшая и неудобная система. Её замена и реформирование доставляло сложности, так как любые существенные изменения в стандартной библиотеке Python воспринимались со всей строгостью со стороны сообщества, учитывая, что это влияет на огромное количество проектов. Возможность нарушить совместимость приводила к тому, что любые нововведения вводились крайне осторожно и редко.
В итоге на рынке появились инструменты, созданные сообществом. Сначала это были easy_install и setuptools — инструменты, созданные для упрощения процесса распространения Python-пакетов. Особенно популярным стал setuptools, который стал своего рода де-факто стандартом для создания и распространения библиотек. Однако вместе с ростом популярности набора инструментов, у сообщества возникла успешная, но и сложная ситуация: слишком много кода и слишком высокая степень зависимости проектов от старого инструментария делала все изменения рискованными и непопулярными. Это привело к тому, что setuptools долгое время оставался достаточно консервативным и не мог за короткий срок радикально измениться.
Новое время принесло появление pip — современного менеджера пакетов для Python, который значительно упростил установку и обновление библиотек. Pip вырос из усилий таких разработчиков, как Ян Бикинг, и стал стандартным инструментом для работы с пакетами. Появление pip позволило переломить ситуацию и перевести экосистему Python к более современным и удобным практикам управления зависимостями. Тем не менее, и pip не входит в состав ядра Python, а распространяется как отдельный проект, развиваемый сообществом. Параллельно с этим в научном сообществе появился conda — отдельный менеджер пакетов и сред, который стал особенно популярен в сферах, связанных с научными вычислениями, машинным обучением и аналитикой.
Conda позволяет эффективно управлять как Python-пакетами, так и системными библиотеками, что делает ее незаменимым инструментом для армий исследователей и специалистов. Conda является независимым проектом, существующим отдельно от core development Python. Таким образом, эволюция систем управления пакетами в Python демонстрирует довольно уникальный пример, когда функционал, чрезвычайно важный для повседневной работы с языком, отсутствует в стандартной сборке и развивается сообществом. Это связано с историческими, организационными и культурными причинами, среди которых ключевым фактором стало отсутствие интереса у руководства проекта и базовой команды разработки. Несмотря на отдельность пакеджинга, сообщества и core devs во многом взаимодействуют.
Многие разработчики активно участвуют в обоих направлениях, способствуя распространению опыта и лучших практик. Это позволяет поддерживать достаточно высокий уровень качества инструментов и обеспечивать интеграцию с самим языком. Подытоживая, можно отметить, что разделение развития Python и систем упаковки отражает уникальное сочетание независимости, гибкости и сложности: с одной стороны, ядро языка остаётся сосредоточенным на разработке интерпретатора и стандартной библиотеки, а с другой — упаковка развивается динамично, благодаря усилиям сообщества и сторонних проектов. Это выгодно тем, что позволяет системам управления пакетами экспериментировать и эволюционировать быстрее и свободнее, без бюрократических ограничений ядра. С другой же — отстраняет их от непосредственного влияния основных разработчиков Python, что иногда ведёт к фрагментации и сложности в выборе инструментов.
В будущем вопрос более тесной интеграции упаковки и ядра Python может стать предметом обсуждений. Однако на данный момент такая модель развития остаётся оптимальной и соответствует интересам и структуре сообщества и проекту в целом.
