splime 0.4.9: как установить зависимости в Python без Docker и конфликтов пакетов

Проблему знает каждый, кто переиспользует Python-код между проектами. Одному проекту нужна одна версия библиотеки, другому другая, и начинается возня: менять lockfile, поднимать Docker-контейнер или превращать десять строк кода в отдельный сервис. Инструмент splime предлагает иной путь, описанный в свежем техническом руководстве. Источник: документация splime (статья из серии о splime 0.4.9).

Функция работает в своём окружении, а ваш проект не знает о её пакетах

• Изолированные зависимости без Docker. Вы описываете функцию и указываете, какие пакеты ей нужны (например, python-dateutil версии 2.9.0.post0). Локальный демон (фоновая программа, которая работает на вашем компьютере) сам создаёт для неё отдельное виртуальное окружение, то есть venv (virtual environment, изолированная папка с нужными библиотеками). Ваш основной проект эти пакеты не видит и не устанавливает.

• Автоматическое определение зависимостей. Если вы публикуете функцию через client.publish() и пакет импортирован на уровне модуля, splime сам находит его имя и версию через стандартные средства Python. Вручную прописывать зависимости нужно только когда импорт спрятан внутри тела функции.

• Кэширование по хешу спецификации. Демон вычисляет хеш из версии Python, списка пакетов и способа сборки. Одинаковый набор зависимостей использует один и тот же готовый venv. Изменили версию пакета, появляется новый хеш и новое окружение, старое не перезаписывается. Два разных объекта с одинаковыми зависимостями делят кэш, а несовместимые наборы не смешиваются.

• Поддержка uv как сборщика. Если в системе установлен uv (быстрый менеджер пакетов Python), splime создаёт переносимый venv командой uv venv --relocatable и ставит зависимости через uv pip install --strict. Без uv используются стандартные venv и pip. Выбранный сборщик тоже входит в хеш, чтобы окружения разных типов не конфликтовали.

• Защита от неполных публикаций. Если сторонний модуль нельзя связать с установленным пакетом, публикация завершается ошибкой, а не создаёт объект с недостающими зависимостями.

Как попробовать за четыре шага?

Руководство рассчитано на macOS и Linux с Python 3.13 и выше. Для первой сборки venv нужен доступ к PyPI (репозиторий пакетов Python).

1. Создайте чистое окружение и установите splime. В терминале выполните: python3.13 -m venv .venv . .venv/bin/activate python -m pip install "splime==0.4.9" Так вы решаете задачу «как установить зависимости в python» для самого splime, не затрагивая системные пакеты.

2. Запустите демон. Задайте отдельную домашнюю директорию для демона, чтобы эксперимент не смешался с вашими реальными объектами, и запустите его: export SPL_DAEMON_HOME="$PWD/.splime-article-daemon" spl-daemon serve --auto-port Флаг --auto-port пригодится, если стандартный порт 8765 уже занят.

3. Создайте файл demo.py с функцией и её зависимостями. В соседнем терминале активируйте то же окружение, создайте файл с описанием функции в формате YAML (текстовый формат для структурированных данных) и вызовите её через SPLClient. Полный код приведён в документации splime.

4. Запустите и проверьте результат: python demo.py Первый вызов может занять несколько секунд на сборку окружения. В итоге вы увидите, что dateutil в вызывающем коде отсутствует (None), а функция при этом вернула правильный результат (29 дней между датами), используя свою версию пакета.

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

Чем отличается от Docker и от российских инструментов?

Docker решает ту же задачу изоляции, но ценой контейнера, образа и инфраструктуры. Для десяти строк кода это часто избыточно. splime работает легче: локальный демон, отдельный venv, никаких образов.

Прямых российских аналогов splime на момент публикации нет. Из ближайших инструментов, которые доступны в РФ: стандартные venv и virtualenv решают проблему изоляции окружений, но не автоматизируют вызов функции из чужого окружения. Docker доступен, но, как сказано выше, тяжеловесен для таких задач. YandexGPT и GigaChat к данной задаче не относятся: это языковые модели, а не менеджеры пакетов.

Для аудитории, которая работает с Python в РФ, ключевое ограничение: splime 0.4.9 требует POSIX (стандарт совместимости операционных систем семейства Unix), то есть работает на macOS и Linux, но не на Windows напрямую. Windows-пользователям понадобится WSL (подсистема Windows для Linux).

Что делать с этим прямо сейчас, по ролям?

Автору на Дзене, который пишет код для автоматизации контента. Если у вас есть Python-скрипты для парсинга, обработки данных или генерации текстов и вы переиспользуете их между проектами, splime позволяет не думать о конфликтах версий. Опубликовали функцию один раз, вызываете из любого проекта.

Разработчику или техническому маркетологу. Подход заменяет сценарий «поднять микросервис ради одной функции». Если в команде несколько проектов на Python с разными версиями библиотек, кэширование по хешу экономит время на повторной сборке.

Предпринимателю без технического опыта. Если ваша команда жалуется на «конфликт зависимостей» и тратит часы на настройку окружений, покажите им эту заметку. splime бесплатен и не требует Docker.

Частые вопросы

Нужен ли Docker для работы splime?

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

Что будет, если я обновлю версию пакета в описании функции?

Появится новый хеш спецификации и новое окружение. Старое останется нетронутым. Два вызова с разными версиями одного пакета используют разные venv и не конфликтуют.

Работает ли splime на Windows?

Версия 0.4.9 требует POSIX, то есть macOS или Linux. На Windows понадобится WSL, подсистема Windows для Linux, которая устанавливается одной командой из Microsoft Store.

Если вы давно откладывали задачу «навести порядок с зависимостями», splime 0.4.9 даёт конкретный инструмент: не философию управления пакетами, а рабочий демон, который собирает окружение за вас и кэширует его для повторного использования.