Пакетные менеджеры (скажите, как правильно)

Всё сугубо индивидуально и зависит от многих факторов. Где-то достаточно системных, где-то нужно более свежее, и пользуют то, что предоставляет экосистема языка.

UVы

У языков программирования есть собственные пакетные менеджеры для установки библиотек

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

в проде. приложение засовывают в докер, а там минимальная среда для запуска интрпретатора того же питон. и все питоновские пакеты ставятся через pip. и даже без использования докера правильно использовать pip с виртуальными окружениями, а сам питон ставить через pyenv и аналоги, чтобы не было конфликтов с системными зависимостями. с другими языками делается все абсолютно так же, хотя, наверное, можно какие-то пакеты для ноды поставить через пакетный менеджер, но 99% нужных в репах нету

У меня был момент, когда пришёл на новую работу, а там были системы, где библиотеки ставились вперемешку (в проде).

зато у них работают парни из яндекса и пишут hashmap’ы на собесах? придурков много и айтишники - это как правило клинические идиоты

Для разработки, удобнее использовать ПМ от языка программирования. При установке на целевые системы, зависит от целевой системы.

В Solaris поэтому и отделили системные библиотеки от пространства пользователя. Совать в древнее ядро дебилиана новейшие библиотеки это идиотизм. Правильного тут нет, так как это свобода выбора - можно быть дебилом, правда. Так что если язык не влияет на работу системы - можно ставить новые библиотеки и прочее. На линуксе это значит, что ломать пыхтон к примеру будет глупо.

Кому должны то?

В NixOS как тебе будет угодно хоть:

• глобально в систему

• конкретному юзеру

• в docker

• в виртуальное окружение (virtual environment) nixshell без всякой установки вообще

Какой дистрибутив используете? Я просто сталкивался с такой политикой только в Hyperbola GNU/Linux-libre.

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

Только что-то самое распространенное и там будет не самая свежая версия, если библиотека в активной разработке. Так что лучше сразу юзать ПМ ЯП, чтобы потом не переделывать)

Держись от этой чуши подальше.

И youtube-dlp ты ставишь чисто из пакетов, да?)

Hyperbola GNU/Linux-libre совсем не использует python и perl? Удивительно! Я думал, в 2025-м году это уже невозможно.

Пакеты должны устанавливаться через системный пакетный менеджер

Собираем на хомяке билды для гругих платформ/дистров/систем? Да ну бред какой-то. Все обязаны страдать как мы страдали.

И youtube-dlp ты ставишь чисто из пакетов, да?)

Ну вообще – да.

❯ dnf.info yt-dlp      
Updating and loading repositories:
Repositories loaded.
Installed packages
Name            : yt-dlp
Epoch           : 0
Version         : 2025.01.26
Release         : 1.fc41
Architecture    : noarch
Installed size  : 20.3 MiB
Source          : yt-dlp-2025.01.26-1.fc41.src.rpm
From repository : updates
Summary         : A command-line program to download videos from online video platforms
URL             : https://github.com/yt-dlp/yt-dlp
License         : Unlicense
Description     : yt-dlp is a command-line program to download videos from many different online
                : video platforms, such as youtube.com. The project is a fork of youtube-dl with
                : additional features and fixes.
Vendor          : Fedora Project

Если python и этого нет в репах, или есть, но не той версии, то ИМХО лучше сделать venv или аналог и гадить уже там. Если что-то сломается, то всегда можно будет начать с нуля, пересоздав окружение.

golang использует каталог из переменной GOPATH под свои нужды. rust гадит в ~/.rust. Скорее всего это тоже можно переназначить, но я не копал.

Из «системонебезопасного» получается только python, но и в нём pip обычно гадить в /usr/local. Если системные библиотеки не трогать, то по идее тоже должно работать.

приведи пример какой язык программирования интересует. касательно php в системе все старое. ставлю свежий php из репозитория и скачанный composer и ПО оттуда.

Докер это максимум для локальной разработки или тестирования, никому не пожелаю докер в проде

Мне нужно сварить бульон. Как правильно будет купить курицу в гипермаркете или на базаре?

Debian/Devuan.

Нет, я его качаю wget-ом, да ещё и патчу каждый раз своим патчем. Это не совсем удобно, да, но вопрос был не про это, а про всякие левые пакетные менеджеры типа pip и подобного бреда. Ими я никогда не пользовался.

вопрос был не про это, а про всякие левые пакетные менеджеры типа pip и подобного бреда

Со странички youtube-dlp

You can install yt-dlp using the binaries, pip or one using a third-party package manager.

Да, через pip можно ставить всякие питоньи тулзы

Я в курсе. Но, повторю, pip я не пользовался и не собираюсь, а вопрос был именно про ему-подобное, а не про wget.

В проектах обычно присутствует файл проекта (манифест), где описаны зависимости и их версии. Сначала от этого отталкиваться. А потом, смотреть на целефую платформу для прода. Хотя, очень странно: думал, что стандарты деплоя сформировались, и основаны на конфигах проекта, и пакеты системы стоят на втором плане.

Раньше ставил пакеты через системный менеджер пакетов (apt, rpm). Но там далеко не всё есть и старые версии. Так что потом перешел на pip/composer. Потом добавил venv для разных проектов.

Сейчас всё в докере, в тыщщу раз удобнее менеджить и не засорять систему.

По хорошему можно собирать проект в какую-нибудь отдельную папку /opt/moi-mega-servise и потом из этого делать пакет под систему, таким образом у тебя сохраняется и удобный способ хранения, доставки, обновлений, откатов на предыдущую версию, и софт твой ты собираешь как хочешь, хочешь системные зависимости используй, хочешь все с собой тащи. Но это сложно и для дедов, молодые все в контейнеры кладут и видеть линукс не хотят.

не пиши чушь в духе фирфакса. веб-приложения разрабатываются везде как я написал. как ты хочешь - это какие-то провинциальные уеб-студии, где нет взрослых

Ну да, если твой уровень - сайтики с апишкой на 100 ботов в день, докер пойдет, но это детская игрушка на коленках, которая скоро уже умрет и уступит место более продвинутой контейнеризации.

Нормально, не в стиле Фиркакса?

Если в ПМ дистриба есть версии пакетов, которые ты используешь в проекте(и ты не используешь докер), то можно использовать его. Иначе — ПМ твоего языка.

ну ты и херню пишешь… докер - это просто обертка над встроенными возможностями ядра типа namespaces и cgroups. оверхед от его использования стремится к 0

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

Ну оверхед оверхедом, он есть. Докер в первую очередь неудобен тем, что это очередной слой абстракции.

В целом проблема контейнеров - доступ к общим данным, когда тебе надо чтобы одно приложение записало файлик, а второе прочитало. Сидим настраиваем бинды папок на машинах, снова возвращаемся на слой ниже, в ОС. Ломаем тот самый плюс что докер это «просто докер файл написал и на любой машине запустил»

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

В итоге, если у тебя что-то сложнее, чем тупая апишка с одним портом наружу или телеграм бот, получаем шило на мыло.

те ты систему должен не обновлять, чтобы твой говносайт не сломался… это ж очевидно… должно быть…

Это если твой системный пакетный менеджер не умеет устанавливать пакеты твоего ЯП.

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

В идеале ставить библиотеки из репозитория. И только если чего-то не хватает для конкретного проекта из-за его особенностей подтягивать что-то со стороны.

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

Я использую пакетные менеджеры языков

И так и так правильно. Смотря как потом софт пакетировать будете. Если распространять через docker/snap - нет смысла завязываться на системных либах. Если через пакетную систему дистрибутива, лучше то, что можно притащить из системы тащить из системы, и прописывать в зависимостях результирующего пакета.

а какой системный пакетный менеджер умеет устанавливать пакеты хотя бы питона?

nix может, guix скорее всего тоже.

Пакеты дистрибутива предназначены для изготовления рабочей операционной системы, где тщательно подобраны и заморожены версии всего, наложены патчи (в том числе что сам мейнтейнер написал) и аккуратно ведутся обновления, чаще всего выборочно минорные версии.

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

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

Пакетный менеджер дистрибутива.

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

В macOS, например, если Питон 3.12+ поставлен из brew, то для того, чтобы воспользоваться ейным pip, его потребуется запустить с говорящей за себя опцией --break-system-packages (т.е. pip --break-system-packages). В большинстве случаев ничего не ломается, но, тем не менее, такой подход считаю правильным.

разве? как будет выглядеть команда pip3 install my_lib через никс?

не. ты бредишь. в пипе лет 10 назад уже было больше 100.000 пакетов. питонвские эти пакеты часто идут как зависимости к каким-то утилитам типа yt-dlp и тогда они есть в стандартных репозиториях, но не пакеты для разработкм веб-приложений, те как ты хочешь просто нельзя, хотя если тебе ничего кроме requests не нужно, то ты его сможешь через системный пакетный менеджер поставить. и в дистрах блокируют возможность ставить что-то через pip, чтобы ты создавал виртуальное окружение, а не пытался себе отстрелить член

в никсе пакетов раз в 10 меньше чем в npm том же, и в разы чем в pypi

…про 10 раз я был не прав, в npm уже 2 миллиона пакетов. и ни один полудурок не будет задрачиваться перенесением их в стандартную репу никса или аур - это не имеет смысла. смысл есть только для зависимостей утилит и прог

Пакетные менеджеры (скажите, как правильно)

«Пакетные менеджеры, скажите, как правильно.»

Далее пишешь что-то сомнительное. А пакетные менеджеры тебе прямо в чят с вертушки отвечают. Или нет.