Идея (ещё одного) шаблонизатора проектов. Нужно ли?

[Aleksey Pirogov]

Доброго всем времени суток!

Насмотревшись тут на днях на всякие https://github.com/n8han/giter8 и прочие http://yeoman.io/, подумал: да, есть ненулевое кол-во инструментов, в т.ч. и ЯП-агностичных, для шаблонизации проектов.Но:

1. многие из ник тянут с собой свой рантайм: я ещё могу терпеть giter8=JVM+sbt+scala, но yeoman=npm=Node - сразу меня отвращает (такой у меня пунктик). Из JMV-based ещё есть lein - тоже умеет шаблонизировать проекты, имеет декларативное описание сценария шаблонизации и довольно компактен. Есть и Python-based тулзы с той же проблемой - требуют рантайм (хоть питон сейчас и стоит на большинстве xNIX-машин) . Всё это громоздко, имхо.
2. большая часть инструментов, как мне кажется, слишком вдохновлена языками, на которых оные реализованы. И пусть на Python ещё более-менее можно конфигурировать проекты, ибо он достаточно простой для этого, зато об DSL giter8 можно и глаза сломать, а уж расширять его - совсем непросто.
3. Большинство из инструментов не умеет ничего делать с уже отшаблоненым проектом, а хочется интеграции - главу к книге добавить (вместе с обновлением TOC), пост к сайтику. Т.е. некоей автоматизации в течении всей работы с проектом.

Теперь вот мне хочется свой инструмент написать. Думал писать на Rust в целях изучения оного, но в итоге решил, что тот слишком низкоуровнев для данной задачи, да и в целом не нужен здесь - особой производительности не требуется, а нативное приложение можно и на Haskell собрать
В первом приближении хочется:

• как у всех - подтягивания болванки проекта с github с необходимым именованием файликов и проч;
• шаблонизации структуры проекта в т.ч. и силами сторонних - родных для ЯП - утилит. Пример: сначала cabal init, а потом добавление доп. файлов в проект и модификация созданных cabal'ом;
• возможности последующего расширения (скажем, на Lua) плагинами, в т.ч. заточенными прямо на конкретный проект (и находящимися прямо в дереве проекта);
• минимальных зависимостей для самого инструмента: единый бинарник будет ок

Что же я хотел таки спросить: стоит ли таким инструментом заморачиваться (не образования для, а конечной пользы ради)?
А может лучше плюнуть. и написать всё на shell + awk + sed, или, скажем, на Python?
Или же стоит допилить что-то уже существующее?

[Alexander (qnikst) Vershilov]

Здравствуйте.

На мой скромный взгляд у данной имеи есть следующие проблемы:

1. Создание проекта занимает околонулевое время по сравнению с остальным временем жизни
2. Часто разработчику проще скопировать релевантные части из других проектов.
3. Мнения по поводу правильности шаблонов может существенно различаться.

Поэтому на мой взгляд проект может быть интересен начинающему разработчику,
или при создании проекта нового типа, с которым раньше не работал. При этом сам
проект должен тащить за собой как можно меньше зависимостей и легко обновляться.
В итоге идеальной реализацией такого проекта может быть Web-сервис интегрированный
с репозиторием, так чтобы человек не регистрируясь мог на него зайти, пройти процесс
создания желаемой конфигурации и автоматически создать репозиторий с собравшимся
шаблоном. Ну и естественно должна быть простая возможность добавления новых конфигов
рейтинги и комментарии и прочая ерунда. Если следовать идеологии github-головного мозга,
то сами шаблоны для языка должны быть репозиторием с какими-то хитрыми файлами
конфигурации по которым строится "мастер конфигурации" и генерируется проект, в этом
случае автоматически появится механизм добавления новых шаблонов и управления ими.

Поскольку в форме проект будет в форме веб-сервиса то вопрос инструментов для его
реализации автоматически не ставится, поэтому Haskell тут вполне подойдёт.
При этом такого проекта вроде еще нету.


воскресенье, 18 января 2015 г., 18:42:04 UTC+3 пользователь Aleksey Pirogov написал:

[Алексей Пирогов]

- Не всегда возможно/удобно пользоваться публичным репозиторием для хранения болванок.

- Хочется также возможности иметь локальный набор шаблонов с возможностью пользовать из вообще без интернета. Пусть даже это будет локальный кэш.

- Клонировать болванку в виде репозитория тоже далеко не всегда нужно.

- Реализовать вебсервис, расширяемый функционально пользователями, удобно и безопасно - та ещё задача. В отличие от локального бинарника и папки lua-скриптов.

Вот социальную часть и весь контент можно хранить и силами сервиса, тут соглашусь. Но локальной версии это не противоречит.

19 января 2015 г., 18:50 пользователь Alexander (qnikst) Vershilov <alexander...@gmail.com> написал:

--
Вы получили это сообщение, поскольку подписаны на одну из тем в группе "Русский Haskell".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/haskell-russian/fxaXhgFQYX0/unsubscribe.
Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес haskell-russi...@googlegroups.com.
Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес haskell...@googlegroups.com.
Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/haskell-russian/86445a6e-8268-4405-8768-b7a23f9f4038%40googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

[Alexander (qnikst) Vershilov]

понедельник, 19 января 2015 г., 19:02:17 UTC+3 пользователь Aleksey Pirogov написал:

- Не всегда возможно/удобно пользоваться публичным репозиторием для хранения болванок.

Не упускайте возможность монетизации. Возможность использования приватных шаблонов
всегда можно продавать, так и работают большинство сервисов вокруг проекта github (например).

- Хочется также возможности иметь локальный набор шаблонов с возможностью пользовать из вообще без интернета. Пусть даже это будет локальный кэш.

Да, согласен с этим проблемы.
 

- Клонировать болванку в виде репозитория тоже далеко не всегда нужно.

Дать пользователю скачать архив же никто не запрещает?
 

- Реализовать вебсервис, расширяемый функционально пользователями, удобно и безопасно - та ещё задача. В отличие от локального бинарника и папки lua-скриптов.

Лично для себя я вообще не вижу необходимости в такой задаче, т.к. скопировать шаблон
если он есть занимает около нулевое время. Задача усложняется если шаблона нету, и стоит
вопрос его поиска.

Все это мои 2с, т.е. странным инструментом будь это код на haskell, lua сприпты или что ещё
берущим мои шаблоны (бесмысленно) или непонятно откуда я бы пользоваться не стал.
 

[IC Rainbow]

> На мой скромный взгляд у данной имеи есть следующие проблемы:

Поздно. Я уже сделал (=

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

Но самое вкусное впереди. Это получение шаблонов по разным "протоколам". Например простое "~/lame.yaml" это файл, "http://hipstername.tld/templates/lame" тоже всем понятно. Интересней их вытаскивать из всяких публичных реестров - "bower:bootstrap","gist:wiz/c32460e1ecbf612bb12f" и тому подобное. Имея один только HTTP клиент уже можно задискаверить и выкачать из кучи мест - без какой-либо нужды в собственной инфраструктуре.

Тоже самое и для репозиториев с, собственно, содержимым шаблона. Есть адрес, есть шелл, надо просто попросить систему и она всё сделает.

Я бы с удовольствием такой штукой пользовался ибо раз за разом после инициализации очередного йесодопроекта надо возиться с приведением его в божеский вид. И таких "сценариев" накапливается довольно много со временем...

[Aleksey Pirogov]

А могу я поучаствовать в разработке?

понедельник, 19 января 2015 г., 22:23:07 UTC+3 пользователь IC Rainbow написал:

[IC Rainbow]

Я выложу чуть попозже. Надо причесать код, а то там сейчас сплошная жопакита...

--
Вы получили это сообщение, поскольку подписаны на группу "Русский Haskell".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес haskell-russi...@googlegroups.com.

Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес haskell...@googlegroups.com.

Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/haskell-russian/d55810e7-9062-41c8-aff8-c73a2e5b147c%40googlegroups.com.

[Maxim Avanov]

Приветствую!

Как насчёт https://github.com/audreyr/cookiecutter ?  Умеет оффлайн.

Примеры использования для Python и Ansible:

* https://github.com/avanov/ansible-role-template

* https://github.com/avanov/python_project_template

[Алексей Пирогов]

Здравствуйте!

Вот за эту ссылку искренне Вас благодарю! Это уже очень похоже на то, что я хотел "свелосипедить". В этом инструменте нет доработки уже созданных проектов, а это мне особенно интересно. Возможно, я смогу такое поведение добавить к cookiecutter'у, вместо умножения кол-ва сущностей.

20 января 2015 г., 23:20 пользователь Maxim Avanov <maxim....@gmail.com> написал:

--

Вы получили это сообщение, поскольку подписаны на одну из тем в группе "Русский Haskell".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/haskell-russian/fxaXhgFQYX0/unsubscribe.

Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес haskell-russi...@googlegroups.com.

Чтобы отправлять сообщения в эту группу, отправьте письмо на электронный адрес haskell...@googlegroups.com.

Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/haskell-russian/8797a5b7-5b90-4816-8bf4-2e74f4760abe%40googlegroups.com.

[Aleksey Pirogov]

Добрый день!
Наткнулся на https://github.com/diecutter/diecutter / http://diecutter.io/ - шаблонизатор проектов, как говорится "as a Service". Open Source, умеет шаблонизировать через REST и через web-формочки.
Возможно, Вам будет интересно.

понедельник, 19 января 2015 г., 19:26:54 UTC+3 пользователь Alexander (qnikst) Vershilov написал:

[Maxim Avanov]

Прекрасный сервис, спасибо!

Продолжая начатую тему. Если всё же очень хочется иметь один бинарник без зависимостей, и при этом нас устраивает реализация идеи в cookuiecutter/diecutter, то можно портировать код на Haskell. В cookiecutter его не так много и он тривиален, самая сложная часть - имплементация лексера  для jinja-подстановок. Заодно можно будет сравнить выразительность языков на конкретном примере и оформить в виде статьи. Похожим методом уже однажды сравнивали Python и OCaml, и на мой взгляд получилось очень продуктивно - http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ 

[Алексей Пирогов]

Добрый день!

Меня лично устраивает и cookiecutter - всё же Python, это достаточно популярный рантайм. К тому же сам я - pythonista со стажем.
Однако польза от Haskell-driven инструмента м.б. вполне осязаемой. Например, дополнительная практика Haskell как такового :)

Попробую поискать что-то уже готовое для jinja-like шаблонов - формат популярный, возможно что-то уже наработано.

21 января 2015 г., 23:49 пользователь Maxim Avanov <maxim....@gmail.com> написал:

Чтобы посмотреть обсуждение на веб-странице, перейдите по ссылке https://groups.google.com/d/msgid/haskell-russian/a8091a63-ebc4-44a8-8c5c-c3e7a809271c%40googlegroups.com.