Comments 15
У flex, имхо, целевая аудитория должна быть — DevOps-ы, но зачем тогда такой узкоспециализированный инструмент?
Почему для devops? Это удобно для быстрых шаблонных проектов.
2) Вот для чего, например, надо сводить в один инструмент git и env? Это же чисто упрощение развертывания, а не разработки. Для разработки всё что делает flex или из шаблонного проекта копипастится, или генерируется IDE.
Также этот инструмент позволяет использовать .env файлы, которые использует тот же docker compose для того, чтобы не пересобирать приложение во время разработки
Так что dotenv — это упрощение именно разработки для тех людей, где прод построен на энвах
Магия для конечного пользователя — куча системных зависимостей получается.
Предположим что мы начали проект с использованием flex и поставили при помощи него 10 пакетов. Наш проект зависит от этих 10-ти пакетов. Можем ли мы добавить еще/удалить их без использования flex? можем. Стало быть зависимости нашего проекта от flex нету. Можем ли мы менять зависимости без composer? можем но сложно, так как наш проект зависит от системы автозагрузки классов composer-а. Однако эта связь осуществляется через абстракцию — slp_autoload. То есть мы можем спокойно заменить ее на свою, но вряд-ли вы будете так делать.
Резюмирую вопрос. Какие кучи системных зависимостей вы видите?
надо сводить в один инструмент git и env?
а откуда взялся git в этой связке? Вы можете использовать symfony flex и без git. Например если все зависимости спокойно можно стянуть по http.
Это же чисто упрощение развертывания, а не разработки.
а вы не разворачиваете то что разработали? Даже локально?
Для разработки всё что делает flex или из шаблонного проекта копипастится, или генерируется IDE.
Давайте прикинем что нам нужно копипастить/генерировать:
- копипастить конфиги модулей, даже если нам требуется дефолтные настройки
- генерировать… да ничего нам не нужно генерировать.
То есть flex — это чисто для копипасты конфигов при установке пакетов. IDE нам тут не поможет. Если вы предлагаете копипастить конфиги из шаблонного проекта — это значит что нам надо сделать такой проект и поставить туда все эти пакеты. Причем даже те которые вам не нужны по дефолту.
К чему это нас приводит:
- жирный стартовый проект переполненный зависимостями которые вам не нужны
- подсознательное стремление разработчиков обойтись тем что есть что бы "не ставить нового ибо надо будет копипастить конфиги уже из ридми".
- усложнение флоу разработки.
Что же предлагает нам flex — лишь возможность разработчикам пакетов описать "настройки по умолчанию" которые в явном виде будут автоматически прописываться в ваш проект. Далее разработчику остается лишь подправить настройки под себя. Отпадает необходимость держать переполненный зависимостями шаблонный проект и использовать ровно то что нужно.
Поддерживаю предыдущего оратора
в чем именно? в том что "целевая аудитория — дэвопсы"?
- devops это идея о том что dev-ы и ops-ы должны меньше сориться и больше общаться. Это и менеджмент конфигураций нормальный и все такое. нынче дефакто стандарт — переменные окружения и секреты, контейнеры и все такое. Это затрагивает обе стороны. Можете подробнее познакомиться с идеями что есть современный бэкэнд: https://12factor.net/
- по поводу магии — это просто плагин для composer. Не вижу никакой черной магии которую стоит бояться.
- мне нравится идея что дефолтные настройки бандла будут сами добавляться и не нужно будет тратить пару минут на редактирование конфигов. Это позволит больше дробить проекты на небольшие пакеты и проще будет их менеджить.
мне в symfony flex нравится все кроме makefile-ов разве что но вроде как от них отказались
А чем именно мейкфайлы не нравятся?
- Лишняя системная зависимость, не везде может быть из коробки, а где-нить под Windows установить непросто, наверное
- Не самый очевидный синтаксис и семантика для тех, кто видит его раз в полгода
- Если говорить именно о symfony, то в большинстве случаев просто ланчер для bin/console, иногда с фолбэками, иногда просто ошибку выводящий
Для начала нам понадобится консольтная утилита symfony lnstaller:
Как раз она нам и не понадобится. И это видно дальше по тексту. Symfony Flex — это замена инсталлятору. Реализованная в виде плагина к composer. С помощью этого плагина можно поставить и предыдущие версии Symfony (3.3 точно ставится).
Суть улучшения в более кросс-технологичных соглашениях (public vs web, config vs app/config, .env vs app/config/parameters.yml, *.yaml vs *.yml, etc). И в большей автоматизации на основе этих соглашений. Отдельные элементы автоматизации методично добавлялись и вылизывались в течение всех релизов третьей ветки (а некоторые появились ещё в 2.x).
Магия там под строгим контролем: любая неоднозначность при компиляции заканчивается бросанием исключения. И требует ручного конфигурирования.
Но, если совсем грубо, правильно описанные и разложенные абстракции, позволяют автоматически нагенерить очень много конкретики. И получить гораздо больше удовольствия от замечательного шаблона DI.
А управление внешними зависимостями позволило более аккуратно нарезать артефакты. Что позволяет не только устанавливать зависимости пачками, но и по-настоящему удалять их пачками в автоматическом режиме. При этом, везде остаётся возможность переконфигурировать, положить в другое место, написать свой рецепт…
Будущий релиз Symfony 4.0 и проект с использованием Symfony Flex