AB
+. По-моему в Гите такой синтаксис
Ага, плюс это работает в конфигах симфони, но там не просто glob 🙂
Size: a a a
2020 November 13
2020 November 14
D
Все привет! Чатик по yii3 есть, ура)
А
Привет!
А
Как мало человеку для счастья надо 😊
А
А то ходят тут всякие, релиз им подавай...
S)
А то ходят тут всякие, релиз им подавай...
👍🏻😂
D
Для меня это уже как мем (с форумов, чатов, комментов с храбра) - "Когда yii3 ?"
m
только для второго композера*, для первого придется использовать https://github.com/Ocramius/PackageVersions
Мне так нравиться скорость 2 композера, что со старым больше иметь дело не хочется... Мне кажется не нужно пилить yii3 под первый композер...
AB
Мне так нравиться скорость 2 композера, что со старым больше иметь дело не хочется... Мне кажется не нужно пилить yii3 под первый композер...
у меня проекты на симфони, там разницы нет почти за счет flex-а
AB
Мне кажется у тех, кто использует php7.4 по определению второй композер 🙂
SI
Я уже приводил пример. Я правлю конфиг и чтобы приложение "увидело" изменение, я должен вручную дёргать "composer du"
Есть ещё варианты: мы выпилили эту систему сборки конфигов, сделали просто чтение конфигов как в yii2. А проблему производительности и постоянного чтения решили через RoadRunner. Имхо, про php-fpm пора забывать.
NO
1. Тогда теряется смысл этих конфигов. При установке можно так же эти конфиги брать из пакета и тогда не будет этой возни с ребилдом конфигов
2. По условиям задачи - конфиг не часть публичного контракта. Зависимости из конфига не прописываются в require, средствами композера не разрулить
2. По условиям задачи - конфиг не часть публичного контракта. Зависимости из конфига не прописываются в require, средствами композера не разрулить
То вручную, а то автоматически. Подключил и оно работает, плюс в любой момент можешь настроить под себя.
NO
И мы таким образом придем к той системе, которую я форсил: пакеты предоставляют конфиги, но при установке они скидываются в папку конфига приложения.
В таком случае плагину не придется обходить все пакеты и собирать конфиги в кучу, чтобы мёржить. Будет сразу мёржить.
В таком случае плагину не придется обходить все пакеты и собирать конфиги в кучу, чтобы мёржить. Будет сразу мёржить.
+, я то же самое предложил
NO
Есть ещё варианты: мы выпилили эту систему сборки конфигов, сделали просто чтение конфигов как в yii2. А проблему производительности и постоянного чтения решили через RoadRunner. Имхо, про php-fpm пора забывать.
Это отличный вариант. По-моему уже очевидно, что в попытках родить идеальное управление конфигами только месяцами впустую сливается время. Без этого мега-плагина уже давно бы большую часть зарелизили.
NO
Я вообще не знаю зачем пакетам какие-то файлы конфигов, которые "надо мёржить". Какое-то помешательство на конфигах, как будто без конфига программировать нельзя.
А
Я вообще не знаю зачем пакетам какие-то файлы конфигов, которые "надо мёржить". Какое-то помешательство на конфигах, как будто без конфига программировать нельзя.
Автоматизация -- лучший друг ленивого программиста
NO
Для автоматизации я пишу код. Никогда не слышал, чтобы для автоматизации было обязательно выносить часть кода в конфиг.
NO
Вот банально же решается внятными дефолтами на каждую из настроек. Будет в пакете N классов, у них у всех "внутри" есть свои умолчания. Которые позволяют использовать любой из них в 90% случаев без вмешательства в настройки.
NO
Ну а когда понадобилось поведение отличное от дефолтного, например "localhost" заменить на конкретное имя хоста, можно указать при использовании класса параметры либо конфиг создать..
NO
Просто я вижу что к конфигам так привыкли, что окончательно зациклились на них и уже приплетают без какой-либо необходимости.