Давайте представим ситуацию, когда вам нужно установить на все виртуальные машины (агенты сервера сборки) определенный пакет Python. Но вы не можете изменить образ агента, а загрузка, к примеру из pypi.org или github.com непроверенных пакетов, ограничена. Как тут не вспомнить последние новости про вредоносные изменения в пакете nmp или более свежую информацию про PyPi.
Python использует подход под названием EAFP — Easier to ask for forgiveness, than permission (легче попросить прощения, чем разрешения). Это значит, что проще предположить, что что-то существует (к примеру, словарь в словаре, или в нашем случае модуль в системе) или получить ошибку в противном случае.
Этот подход, развитый в PEP-0302, позволяет делать хук импорта модулей, что в итоге приводит нас к возможности написания следующего кода:
from <какое-то хранилище> import <модуль>
Поскольку я часто сталкиваюсь с автоматизацией развертывания CI/CD с помощью Bamboo, то для меня естественным решением было разместить код выверенного модуля в артефактах JFrog и написать (согласно PEP-0302) классы finder и loader для загрузки и установки модулей. В моем случае код импорта модулей выглядит следующим образом:
from <artifactory_local.path_to_ artifactory> import <module_tar_gz>
Согласно PEP-0302 в протоколе участвуют два класса: finder
и loader
.
Продемонстрирую модуль amtImport.py, реализующий работу этих классов:
import sys
import pip
import os
import requests
import shutil
class IntermediateModule:
"""
Module for paths like `artifactory_local.path`
"""
def __init__(self, fullname):
self.__package__ = fullname
self.__path__ = fullname.split('.')
self.__name__ = fullname
class ArtifactoryFinder:
"""
Handles `artifactory_local....` modules
"""
def find_module(self, module_name, package_path):
if module_name.startswith('artifactory_local'):
return ArtifactoryLoader()
class ArtifactoryLoader:
"""
Installs and imports modules from artifactory
"""
artifactory_modules: list = []
def _is_installed(self, fullname):
try:
self._import_module(fullname)
ArtifactoryLoader.artifactory_modules.append(fullname)
return True
except ImportError:
return False
def _import_module(self, fullname):
actual_name = '.'.join(fullname.split('.')[2:])
actual_name = actual_name.replace('_', '.').split('.')[0]
return __import__(actual_name)
def _install_module(self, fullname):
if not self._is_installed(fullname):
actual_name = '.'.join(fullname.split('.')[2:])
url = fullname.replace('artifactory_local', '').replace(actual_name, '').replace('_', '/')
actual_name = actual_name.replace('_', '.')
url = 'https://artifactory.app.local' + url.replace('.', '/') + actual_name
auth = (os.getenv("bamboo_artifactory_user_name"), os.getenv("bamboo_artifactory_access_token_secret"))
file_name = f"{os.getenv('bamboo_build_working_directory')}/{actual_name}"
with requests.get(url=url, auth=auth, stream=True) as r:
if r.status_code != 200:
raise Exception(f"Status code {r.status_code}: {r.reason}")
with open(file_name, 'wb') as f:
shutil.copyfileobj(r.raw, f)
pip.main(['install', file_name])
ArtifactoryLoader.artifactory_modules.append(fullname)
def _is_repository_path(self, fullname):
return fullname.count('.') == 2
def _is_intermediate_path(self, fullname):
return fullname.count('.') < 2
def load_module(self, fullname):
if self._is_repository_path(fullname):
self._install_module(fullname)
if self._is_intermediate_path(fullname):
module = IntermediateModule(fullname)
else:
module = self._import_module(fullname)
sys.modules[fullname] = module
sys.meta_path.append(ArtifactoryFinder())
(Код тестировался для Python 3.6)
Итог: динамический импорт из артефактов можно лаконично оформить следующим кодом:
from amtImport import ArtifactoryLoader
# pyright: reportMissingImports=false, reportUnusedImport=false
from artifactory_local.artifactory_amt_Sealed import smbprotocol_1_9_0_tar_gz
if "artifactory_local.artifactory_amt_Sealed.smbprotocol_1_9_0_tar_gz" in ArtifactoryLoader.artifactory_modules:
print("Package successfully loaded")
Используя аналогичный подход, можно организовать импорт модулей из любого другого источника.
P.S. Основой для данной статьи послужил пакет import_from_github_com.
Комментарии (8)
baldr
11.08.2022 19:32+2То есть во время выполнения программа еще что-то начинает себе устанавливать? Это продакшен код у вас так работает? А как насчет того чтобы перечислить список пакетов для установки в requirements.txt или подобном? А если пакет требует какие-нибудь бинарники типа openssl для установки?
Я, честно говоря, не уловил причин для того чтобы так делать. Вам запрещают на сервера устанавливать пакеты? Что за дичь?
Mingun
11.08.2022 23:30Насколько я понял ситуацию, это машины CI / CD, на которых сборка приложения происходит, они во внутренней сети и у них нет доступа к интернету / ограничили доступ к источникам пакетов (например, к github'у), поэтому дополнительные пакеты просто так не поставить сверх того, что есть в базовом образе. Говорю не понаслышке, у меня ровно такая же ситуация, правда, дело касается php и пакетов composer'а.
baldr
11.08.2022 23:52Подождите, это все равно не имеет смысла. Приложению нужен пакет "packageXXX" - его нужно поставить и лучше бы до старта приложения.
В крупных и средних организациях просто выделяется сервер во внутренней сети для организации различных репозиториев (для apt, PyPi, composer, и тп) и на нем располагаются уже проверенные и одобренные версии. У сервера сборки доступ к нему должен быть.
В организациях победнее - просто скачиваются все пакеты в виде .deb, .whl, и пр - и кладутся в папочку вместе с исходниками или монтируются в контейнер для сборки.
Я не могу представить себе ситуации чтобы, например, программист на C пришел и начал рассказывать как у него в рантайме вызывается make и gcc и компилируются части приложения из левых папок.
alisichkin Автор
12.08.2022 08:58В чем то Вы правы, но позволю возразить, приведя в пример gradle (и т.п.) - когда при сборке приложение, выкачиваются отсутствующие библиотеки.
Или в Go - при импорте пакетов вы можете указывать пакеты расположенные в GitHub
import (
"fmt"
"os"
"github.com/digital/ocean/godo"
)baldr
12.08.2022 13:24gradle - система сборки, примерно как и pip. Во время сборки выкачивать пакеты - нормально. В вашем примере с go - они также скачаются еще при сборке, возможно еще на другом компьютере. Хотя мне указание импорта из интернета тоже не кажется хорошей практикой.
Во время выполнения что-то качать дополнительно - плохая идея. Скажем, у меня есть собранный докер-имидж приложения и я запускаю его по расписанию через cron каждые 5 минут (новый контейнер каждый раз). Я не хотел бы чтобы оно каждый раз тратило время и трафик на скачивание одного и того же пакета.
Все пытаюсь понять смысл ваших действий. У вас система сборки качает пакеты для собираемого приложения? Или для себя? Или само приложение скачивает и устанавливает себе пакеты? Почему нельзя запустить "pip install -r requirements.txt" перед запуском скрипта и указать внутренний адрес репозитория, например? Или просто путь к локальным пакетам?
Jsty
Крайне странный подход. Почему через тот же ansible не выполнить установку модуля из того же artifactory?