Зачем питонисту 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Мб+ непонятно чего не понятно зачем.
Если у кого-то есть интерес, желание и возможность, приглашаю продолжить работу. Как появится время, смогу снова в него включиться.
Нам лишнего не надо.
На заметку
Зарегистрированные пользователи могут добавлять Видео.