LINUX.ORG.RU

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

 ,


3

2

Опубликован перевод очередной главы из 1 тома книги «Архитектура приложений с открытым исходным кодом» — «Архитектура системы управления пакетами в Python».

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

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

У каждого подхода есть свои достоинства и недостатки.

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

>>> Подробности

★★★

Проверено: Shaman007 ()
Последнее исправление: unfo (всего исправлений: 1)

Ответ на: комментарий от Napilnik

Да ты неадекват или в гугле забанили - «слишком яркий монитор», раньше ещё гуглилось «монитор прожектор».

Угу, ты рассказывай, рассказывай, это как раз про мой первый писали (самс 971р). Второй тоже по дефолту несносен.

И как ты будешь это делать если его настройками яркость подсветки не уменьшается до комфортного значения? Ну скрутишь ты яркость и контрастность в 0, но только это всё равно слишком ярко.

Мне как раз приходится уменьшать сильно, но всегда этих настроек хватало. Прозреваю кейс «в сумерках / темноте».

Установщики слишком хитрые пошли, по наглому ставят не всё что ты выбрал а потом удивляешься «почему поставилось на час быстрее запланированного», недолго, пока не обнаруживаешь нехватку пакетов в системе.

Первый раз слышу, всегда только обратное видел — ты галку снимаешь, а потом видишь как оно этот пакет ставит, как зависимость наверное.

Никогда не ронял комплектующие на пол? Тогда у тебя всё впереди!

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

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

Сам себе не веришь?

Этот тред требует больше NO U.

anonymous
()
Ответ на: комментарий от anonymous

Мне как раз приходится уменьшать сильно, но всегда этих настроек хватало. Прозреваю кейс «в сумерках / темноте».

На старых аппаратах со ртутными лампами может и хватало но теперь появилась светодиодная подсветка которая и светит сильнее и жрёт меньше - производители могут «увеличивать контрастность» до нереальных величин. Если тебе мониторных настроек _всегда_ хватает, то может ты пользуешься очками с затемнением или болеешь катарактой?

Первый раз слышу, всегда только обратное видел — ты галку снимаешь, а потом видишь как оно этот пакет ставит, как зависимость наверное.

Добавлять пакеты конечно должно, но раньше при начале установки ещё и вылезали баги из-за которых приходилось тыкать галки по новой. Теперь ставится проще, но то нужно в кедах пакеты локализации ставить уже после установки, то все пакеты кед вообще - новые питоноустановщики разруливают свои баги по тихому простым жульническим способом.

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

От монитора зависит выбор видеодрайвера свободный/проприетарный а уронить мышку/винт можно и при не дрожащих руках, наример просто не успеть поймать.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

Если тебе мониторных настроек _всегда_ хватает, то может ты пользуешься очками с затемнением или болеешь катарактой?

Да / нет. Когда сказать нечего, иногда лучше промолчать.

Могу только повториться, что за внешним освещением тоже следить надо.

новые питоноустановщики разруливают свои баги по тихому простым жульническим способом.

Эй, возвращаться на онтопик уговора не было. Если б нам было что сказать, разве б мы пошли на мониторы и винты?

От монитора зависит выбор видеодрайвера свободный/проприетарный

Оригинальная точка зрения. Уникальная, я бы даже сказал.

anonymous
()
Ответ на: комментарий от anonymous

Да / нет. Когда сказать нечего, иногда лучше промолчать

Ну так и промолчи, если сказать нечего.

Могу только повториться, что за внешним освещением тоже следить надо.

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

Эй, возвращаться на онтопик уговора не было. Если б нам было что сказать, разве б мы пошли на мониторы и винты?

У тебя интеллекта не хватило даже на регистрацию, а на то чтобы охватить картину целиком а не по частям и подавно.

Оригинальная точка зрения. Уникальная, я бы даже сказал.

Зато правильная - драйвер должен делать с железом «зашибись», блоб так может а свободный не всегда.

Napilnik ★★★★★
()
Ответ на: комментарий от Napilnik

Спасибо, посмеялсо, это ж какое надо внешнее освещение чтобы прожектор не казался прожектором.

Ну не передергивай, сначала ты на нем самом яркость меняешь.

У тебя интеллекта не хватило даже на регистрацию, а на то чтобы охватить картину целиком а не по частям и подавно.

А у тебя — воздержаться от ad hominem :Р

Зато правильная - драйвер должен делать с железом «зашибись», блоб так может а свободный не всегда.

Лично для меня скорее наоборот, причем именно по функциональности (фичи и баги). Но тут вообще никто не поверит, что это нвидиа.

anonymous
()
Ответ на: комментарий от Nanodesu

Я вот думаю, что если бы у apt и других были бы дочерние деревья пакетов для python, ruby и прочих, все могло бы сложиться иначе.

Но сейчас уже давно принято разводить срач в системе при помощи их самостийных пакетных менеджеров и выступать с таким предложением - все равно что кричать вслед ушедшему поезду.

теоретически, понятно в каком направлении копать: взять какой-то прозрачный пакетный менеджер, например Guix и конвертировать из «самостийных» пакетных менеджеров языка в его «рецепты сборки».

Guix тут интересен тем, что для него «рецепты сборки» пишутся на обычной схеме (guile) — следовательно, теоретически надо всего лишь написать парсер «ебилдов» конкретных «самостiных» пакетных менеджеров и конвертор в «универсальный» формат guix пакетов.

полуавтоматически конвертировать пакетики и отлаживать репозиторий.

ну и/или конвертировать из guix в .deb тоже :)

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

anonymous
()
Ответ на: комментарий от tailgunner

и это нормально

Это ненормально. Это, в общем-то, песец.

ну вот, сбил весь пафос ;-) я как бы намекал на проблемы :))

с другой стороны, то что сообщества пакетов вокруг языка и вокруг дистрибутива (ну или, оверлея/репозитория) — развиваются с разной скоростью, и следовательно, один из них почти «не нужен» — спорить не будешь?

anonymous
()
Ответ на: комментарий от anonymous

Ну не передергивай, сначала ты на нем самом яркость меняешь.

Поменяй яркость подсветки на Fujitsu E19-6 LED. Яркость подсветки нужно уменьшить в разы, т.к. лампочек очень много, а впаянная плата так делать не умеет и равномерно отключать часть лишних ламп тоже не умеет - от этого ж аппарат подорожает на несколько баксов и его _распространители_ не купят.

Лично для меня скорее наоборот, причем именно по функциональности (фичи и баги). Но тут вообще никто не поверит, что это нвидиа.

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

Napilnik ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.