Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 8

Крайне странный подход. Почему через тот же ansible не выполнить установку модуля из того же artifactory?

Что бы подчеркнуть, что это Real Python :)

То есть во время выполнения программа еще что-то начинает себе устанавливать? Это продакшен код у вас так работает? А как насчет того чтобы перечислить список пакетов для установки в requirements.txt или подобном? А если пакет требует какие-нибудь бинарники типа openssl для установки?

Я, честно говоря, не уловил причин для того чтобы так делать. Вам запрещают на сервера устанавливать пакеты? Что за дичь?

Насколько я понял ситуацию, это машины CI / CD, на которых сборка приложения происходит, они во внутренней сети и у них нет доступа к интернету / ограничили доступ к источникам пакетов (например, к github'у), поэтому дополнительные пакеты просто так не поставить сверх того, что есть в базовом образе. Говорю не понаслышке, у меня ровно такая же ситуация, правда, дело касается php и пакетов composer'а.

Подождите, это все равно не имеет смысла. Приложению нужен пакет "packageXXX" - его нужно поставить и лучше бы до старта приложения.

В крупных и средних организациях просто выделяется сервер во внутренней сети для организации различных репозиториев (для apt, PyPi, composer, и тп) и на нем располагаются уже проверенные и одобренные версии. У сервера сборки доступ к нему должен быть.

В организациях победнее - просто скачиваются все пакеты в виде .deb, .whl, и пр - и кладутся в папочку вместе с исходниками или монтируются в контейнер для сборки.

Я не могу представить себе ситуации чтобы, например, программист на C пришел и начал рассказывать как у него в рантайме вызывается make и gcc и компилируются части приложения из левых папок.

В чем то Вы правы, но позволю возразить, приведя в пример gradle (и т.п.) - когда при сборке приложение, выкачиваются отсутствующие библиотеки.
Или в Go - при импорте пакетов вы можете указывать пакеты расположенные в GitHub
import (
"fmt"
"os"
"github.com/digital/ocean/godo"
)

gradle - система сборки, примерно как и pip. Во время сборки выкачивать пакеты - нормально. В вашем примере с go - они также скачаются еще при сборке, возможно еще на другом компьютере. Хотя мне указание импорта из интернета тоже не кажется хорошей практикой.

Во время выполнения что-то качать дополнительно - плохая идея. Скажем, у меня есть собранный докер-имидж приложения и я запускаю его по расписанию через cron каждые 5 минут (новый контейнер каждый раз). Я не хотел бы чтобы оно каждый раз тратило время и трафик на скачивание одного и того же пакета.

Все пытаюсь понять смысл ваших действий. У вас система сборки качает пакеты для собираемого приложения? Или для себя? Или само приложение скачивает и устанавливает себе пакеты? Почему нельзя запустить "pip install -r requirements.txt" перед запуском скрипта и указать внутренний адрес репозитория, например? Или просто путь к локальным пакетам?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий