Какие опции существуют для определения пакета Python с зависимостями node.js?

В настоящее время у меня есть несколько (неопубликованных) пакетов Python для локального использования, которые я устанавливаю (для целей разработки) со сценарием Bash в Linux в активированную (иначе "пустую") виртуальную среду следующим образом:

cd /root/of/python/package
pip install -r requirements_python.txt # includes "nodeenv"
nodeenv -p # pulls node.js and integrates it into my virtual environment
npm i -g npm # update npm ...
cat requirements_node.txt | xargs npm install -g
pip install -e .

Фоном является то, что у меня есть ряд зависимостей node.js, JavaScript CLI-скрипты, которые вызываются моим кодом Python.

Плюсы нынешнего подхода:

  • очень просто: опирается на nodeenv для всей необходимой сантехники
  • теоретически может быть реализовано в рамках setup.py с subprocess.Popen так далее

Минусы нынешнего подхода:

  • Unix-подобные платформы только с Bash
  • "трудно" распространять мои пакеты, скажем, на PyPI
  • требует виртуальной среды
  • имеет потенциально "интересные" побочные эффекты, если пакет установлен глобально
  • потенциально мешает существующей конфигурации / "развертыванию" nodeenv в текущей виртуальной среде

Что такое канонический (если есть) или просто здравый, потенциально кроссплатформенный подход определения зависимостей node.js для пакета Python, делающий его публикуемым?

Почему этот вопрос вообще актуален? JavaScript не только для веб-разработки (больше). Есть также интересные (актуальные) инструменты обработки данных. Если вы не хотите пропустить / игнорировать их, хорошо, добро пожаловать в эту конкретную форму ада.

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

Я начал там проблему, задавая аналогичный вопрос.

РЕДАКТИРОВАТЬ (1): Интересный ресурс: JavaScript против научных вычислений - краткое руководство для тех, кто сожалеет, что это стало необходимым

РЕДАКТИРОВАТЬ (2): я начал проблему с nodeenv, спрашивая, как я могу сделать проект зависит от него.

Источник

2 ответа

(Отказ от ответственности: я автор спокойных)

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

  1. Как разработчик может убедиться, что у него есть вся информация, необходимая для установки пакета, когда он ему предоставляется.
  2. Как проект гарантирует, что основание, на котором он стоит, прочно (т.е. имеет все необходимые зависимости).
  3. Насколько легко пользователю установить данный проект.
  4. Насколько легко воспроизвести данную сборку.

Для одного языка, одного проекта платформы, на первый поставленный вопрос тривиально ответили - просто используйте любое решение для управления пакетами, реализованное для этого языка (например, Python - PyPI, Node.js - npm). Другие вопросы, как правило, становятся на свои места.

Для мультиязычного, многоплатформенного это то, где он полностью разваливается. Короче говоря, именно поэтому проекты обычно имеют несколько наборов инструкций для любой версии Windows, Mac или Linux (из различных основных дистрибутивов) для установки их программного обеспечения, особенно в двоичной форме, для решения третьего вопроса, чтобы было легко для конечного пользователя (который обычно оказывается выполнимым, но не обязательно легким).

Разработчикам и системным интеграторам, которые определенно больше интересуются вопросами 2 и 4, они, вероятно, хотят сценарий автоматизации для любой платформы, на которой они работают. Это то, что вы уже получили, за исключением того, что оно работает только в Linux или там, где доступен Bash. Теперь возникает вопрос: как обеспечить доступность Bash в системе? Некоторые системные администраторы могут предпочесть какую-либо другую форму оболочки, поэтому мы снова возвращаемся к той же проблеме, но вместо того, чтобы спрашивать, существует ли Node.js, мы должны спросить, есть ли там Bash. Так что эта проблема в основном неразрешима, если не проведена линия.

Первый вопрос еще не был упомянут, и я собираюсь сделать это забавно, задав его таким образом: учитывая пакет из npm, для которого требуется пакет Python, как определить зависимость от PyPI? Оказывается, такой проект существует: нет. Я не использовал его раньше, но на первый взгляд это обеспечивает особый способ записи информации о зависимости в package.json Файл, который является стандартным методом для пакетов Node.js, передает информацию о себе. Обратите внимание, что у него есть нестандартный способ управления пакетами Python, однако, учитывая, что он использует любой доступный Python, он, вероятно, будет делать правильные вещи, если виртуальная среда Python была активирована. Это также означает, что у зависимых пакетов Node.js может быть способ выяснить необходимые зависимости Python, которые были объявлены их зависимостями Node.js, но учтите, что без чего-либо еще поверх этого (или какого-либо другого основания /). линия), нет никакого способа утверждать изнутри окружающей среды, что она будет гарантировать то, что должно быть сделано.

Естественно, возвращаясь к Python, этот вопрос уже задавался ранее (но не обязательно полезным для вас образом, поскольку контексты все разные):

В любом случае, quietjs только решает проблему 1 - т.е. позволяет разработчикам иметь возможность выяснить, какие пакеты Node.js им нужны из данного пакета Python, и в меньшей степени помочь с проблемой 4, но без гарантий 2 и 3 это не совсем решено.

С точки зрения управления зависимостями Python, нет способа гарантировать, что необходимые внешние инструменты доступны, пока не будет предпринята попытка их использования (они будут работать или не работать, а также из Node.js, как объяснялось ранее, и спасибо за Ваш вопрос по вопросу трекера, кстати). Если требуется эта конкретная гарантия, многие системные интеграторы будут использовать свой любимый менеджер пакетов уровня операционной системы (например, dpkg/apt, rpm/yum или что-то еще в Linux, Homebrew в OS X, возможно Chocolatey в Windows), но снова это требует дополнительных зависимостей для установки. Следовательно, если нужно поддерживать несколько платформ, не существует общих решений, если только одна не должна была уменьшить область действия или иметь какую-то стандартную непрерывную интеграцию, которая генерировала бы рабочие установочные образы, которые затем можно было бы развернуть на любых службах виртуализации, которые использует организация (просто пример).

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

Источник

То, что вы описываете, конечно, не самая простая проблема. Только для Python компании придумали всевозможные методы упаковки (например, pex в Twitter, dh-virtualenv в Spotify или даже грокер, который переносит развертывание Python в пространство контейнера).

Тем не менее, я могу придумать один очень хакерский способ:

  • Найдите способ скомпилировать ваши Node-приложения в один двоичный файл. Существует pkg ( блог об этом), который

[...] позволяет вам упаковать ваш проект Node.js в исполняемый файл, который можно запустить даже на устройствах без установленного Node.js.

Таким образом, инструменты Node будут заботиться.

  • Затем возьмите эти двоичные двоичные объекты и добавьте их (как-то) в виде сценариев в ваш пакет python, чтобы они распространялись вместе с вашим пакетом и находили свое место, где ваш реальный пакет python может их собрать и выполнить.

расквитаться:

  • Пользователю не нужны никакие nodejs на своей машине (что, вероятно, ожидается, когда вы просто хотите pip install что-то).
  • Ваш пакет становится более автономным, включая двоичные файлы.

Недостатки:

  • Ваш пакет Python будет включать в себя двоичный файл, который встречается реже.
  • Содержимое двоичных файлов означает, что вам придется готовить версии для всех платформ. Не невозможно, но больше работы.
  • Вам придется немного расширить свой конвейер создания пакетов (Makefile, setup.py или другой), чтобы сделать это простым и повторяемым.
  • Ваш пакет становится значительно больше (что, вероятно, является наименьшей из проблем сегодня).
Источник
Другие вопросы по тегам