Зачем питонисту Bower? Питонисту нужен bowerer
Немного размышлений на тему необходимости Bower и Node.js в проектах на Python.
Прежде всего, что такое Bower. Это пакетный менеджер для веб. С его помощью можно довольно просто и удобно управлять пакетами и их зависимостями.
Например, ваше веб-приложение, которое, конечно, написано на Python, используют несколько клиентских библиотек, скажем, jQuery, Bootstrap, Ember и прочие, и вам нужно иметь возможность их установить, а в последующем и обновлять, как можно более просто. Желательно одной командой. А ещё хочется составить список всего нужного, запихнуть в файл, чтобы при необходимости также одной командой поставить/обновить всё это добро. Наверняка вы уже ощутили, что всё это вам знакомо по приложению
То есть, вещь хорошая, нужная. Даром, что этот менеджер написан на JavaScript, если хорошая — качаем, ставим.
И вот примерно на этом шаге приходит осознание, что Bower работает на Node.js. Не знаю кого как, а меня такое положение дел огорчает, ведь эта среда исполнения не маленькая — магабайт 40. И мне не то чтобы жалко, просто не ясно зачем вся эта красота, большей частью которой пользоваться я не собираюсь: на серверной стороне работает Питон, на клиенте — браузерный JavaScript.
И ещё грустнее становится, если залезть в код Bower и понять, что принцип работы довольно прост: нет никакого выделенного сервера с пакетами (такого как PyPI, например), работа ведётся прямо с GitHub; пожалуй самое сложное, что там можно увидеть — это создание графа пакетов и зависимостей с разрешением конфликтов.
В этой грусти некоторое время назад я начал прямое портирование кода этого пакетного менеджера на Python — bowerer. На первых порах прямое портирование с минимальными отличиями от оригинала вполне оправдано — нужно получить заведомо рабочий эквивалент. Портировать, кстати, не сложно, поскольку языки во многом схожи, но довольно муторно. Порт в отличие от оригинала не асинхронный, но это можно будет относительно просто исправить, ведь теперь у нас в арсенале есть async и await.
К сожалению, времени на этот проект не хватает, поэтому сегодня я залил в репозиторий залежавшийся код и оставляю его в подвешенном состоянии. По ощущениям порт завершён процентов на 70. Удельный вес — около 90Кб. Это не 40Мб+ непонятно чего не понятно зачем.
Если у кого-то есть интерес, желание и возможность, приглашаю продолжить работу. Как появится время, смогу снова в него включиться.
Нам лишнего не надо.
Например, ваше веб-приложение, которое, конечно, написано на Python, используют несколько клиентских библиотек, скажем, jQuery, Bootstrap, Ember и прочие, и вам нужно иметь возможность их установить, а в последующем и обновлять, как можно более просто. Желательно одной командой. А ещё хочется составить список всего нужного, запихнуть в файл, чтобы при необходимости также одной командой поставить/обновить всё это добро. Наверняка вы уже ощутили, что всё это вам знакомо по приложению
pip
. Так вот Bower выполняет сходные задачи, но для клиентских библиотек.То есть, вещь хорошая, нужная. Даром, что этот менеджер написан на JavaScript, если хорошая — качаем, ставим.
И вот примерно на этом шаге приходит осознание, что Bower работает на Node.js. Не знаю кого как, а меня такое положение дел огорчает, ведь эта среда исполнения не маленькая — магабайт 40. И мне не то чтобы жалко, просто не ясно зачем вся эта красота, большей частью которой пользоваться я не собираюсь: на серверной стороне работает Питон, на клиенте — браузерный JavaScript.
И ещё грустнее становится, если залезть в код Bower и понять, что принцип работы довольно прост: нет никакого выделенного сервера с пакетами (такого как PyPI, например), работа ведётся прямо с GitHub; пожалуй самое сложное, что там можно увидеть — это создание графа пакетов и зависимостей с разрешением конфликтов.
В этой грусти некоторое время назад я начал прямое портирование кода этого пакетного менеджера на Python — bowerer. На первых порах прямое портирование с минимальными отличиями от оригинала вполне оправдано — нужно получить заведомо рабочий эквивалент. Портировать, кстати, не сложно, поскольку языки во многом схожи, но довольно муторно. Порт в отличие от оригинала не асинхронный, но это можно будет относительно просто исправить, ведь теперь у нас в арсенале есть async и await.
К сожалению, времени на этот проект не хватает, поэтому сегодня я залил в репозиторий залежавшийся код и оставляю его в подвешенном состоянии. По ощущениям порт завершён процентов на 70. Удельный вес — около 90Кб. Это не 40Мб+ непонятно чего не понятно зачем.
Если у кого-то есть интерес, желание и возможность, приглашаю продолжить работу. Как появится время, смогу снова в него включиться.
Нам лишнего не надо.
На заметку
У нас есть новостная группа в Telegram. Там же можно обсудить интересующие вопросы. Ссылка в самом низу страницы.