Ну, все таки, при обычной недоступности спасет кэш-прокси (маловероятно что вам почистят кэши именно в день, когда гитхаб опять забанят).
От внезапного удаления пакета помогает во-первых все тот же кэш прокси (они все таки жалуются, когда пакет пропал при синке), а во вторых --prefer-source при разработке — хоть у кого то из разработчиков да останется пакет в исходном виде (если учесть, что он не обновляется).
В самом крайнем случае код довольно легко извлечь с любого из стендов и уже в момент потери положить в репку, которую подключить в satis\toran\etc.
Мне все это кажется менее геморным, чем постоянно поддерживать несколько сотен форков, все таки пакеты не каждый день пропадают
я просто грустнею даже от самой мысли, что мне бы пришлось поддерживать сотни три форков (да пусть даже и автоматикой, но поддерживать) с полной синхронизацией всех коммитов
саджест все равно в таких случаях некорректен. саджест — это предложение, а в вашем случае без установки такого «предложения» пакет не будет работать. в таких случаях делают по-другому:
реквестят (мета)-пакет «some-vendor/my-super-interface-implementation»
этот пакет не зарегистрирован в packagist, но любой другой пакет (например из вашего списка саджестов) может прописать у себя provides some-vendor/my-super-interface-implementation
таким образом при установке будут разрешены все зависимости, не будет лишних реквайров, но при этом будет явное требование установить что-то что имплементит ваш интерфейс
C газлом возможно неудачный пример, надо было брать какой-нибудь соап клиент, на которых нормальных стандартов не понаписали, а наследоваться от \SoapClient все не хотят
в таком случае
1. у вас в src нигде не будет зависимости от guzzle, только от psr
2. в require у вас будет какой нибудь psr/http-message все равно, т.к он требуется для вашей библиотеки
Очевидно же, что в библиотеке require желательно оставить пустым, а в require-dev пишем, что хотим, так как эти пакеты используются только для разработки и тестирования и к клиенту они не попадут.
я правильно понимаю, что вы заставляете пользователя искать транзитивные зависимости вручную? ну типа у вас есть какой-нибудь api клиент с использованием guzzle, а guzzle нужной версии вы заставляете людей ставить?
А если ваша библиотека написана с использованием nullable, а у человека 7.0, он тоже об этом только опытным путем узнает?
Как сейчас государство отзывает (объявляет недействительными) паспорта, которые лежат у нас в карманах? Принцип примерно тот же — достаточно внести идентификатор в базу. Хранить идентификатор — дешево. Проверить — быстро.
Докер на Win10 работает нативно быстро, если используется Hyper-V драйвер. Тормоза вольюмов VBox можно обойти, настроив файл-синк проекта шторма в руками созданный докер-хост на убунте. Если у вас Win10 — то просто поменяйте подсистему виртуализации и все залетает
Где свели в один инструмент git и env? если вы про dotenv, то по факту это инструмент, позволяющий мокать энвы через файл для локальных окружений, где их тяжело поддерживать одинаковыми путем системных инструментов. Он даже «по канону» включается только тогда, когда не определена перенная APP_ENV в окружении
Также этот инструмент позволяет использовать .env файлы, которые использует тот же docker compose для того, чтобы не пересобирать приложение во время разработки
Так что dotenv — это упрощение именно разработки для тех людей, где прод построен на энвах
Не буду спорить, но у меня на сложных админках уже столько кастома, что проще впиливать полностью свои экраны, чем заморачиваться с кастомизацией что сонаты, что изиадмина.
Свои форм-тайпы там использовать так же просто — вместо встроенных типов указываете класс. Конфигурирование — да, чем то попахивает, с другой стороны проект расчитан именно на простые круд админки. Это прописано у них в фичах — круд, поиск и дизигн. Но для простых админок он гораздо удобней, чем соната. на мой взгляд.
Sonata получила поддержку symfony 3 (из-за FOS UB) только этим летом, что заставило нас отказаться от этого проекта в пользу easy admin в нескольких проектах. Ну и да, «особенностей» у нее полно.
От внезапного удаления пакета помогает во-первых все тот же кэш прокси (они все таки жалуются, когда пакет пропал при синке), а во вторых
--prefer-source
при разработке — хоть у кого то из разработчиков да останется пакет в исходном виде (если учесть, что он не обновляется).В самом крайнем случае код довольно легко извлечь с любого из стендов и уже в момент потери положить в репку, которую подключить в satis\toran\etc.
Мне все это кажется менее геморным, чем постоянно поддерживать несколько сотен форков, все таки пакеты не каждый день пропадают
fingerprint клиента — это в любом случае клиентские подделываемые данные, доверять им не стоит никогда
реквестят (мета)-пакет «some-vendor/my-super-interface-implementation»
этот пакет не зарегистрирован в packagist, но любой другой пакет (например из вашего списка саджестов) может прописать у себя provides some-vendor/my-super-interface-implementation
таким образом при установке будут разрешены все зависимости, не будет лишних реквайров, но при этом будет явное требование установить что-то что имплементит ваш интерфейс
Вот например так работают с тем же PSR-3 логгером
packagist.org/providers/psr/log-implementation
1. у вас в src нигде не будет зависимости от guzzle, только от psr
2. в require у вас будет какой нибудь psr/http-message все равно, т.к он требуется для вашей библиотеки
я правильно понимаю, что вы заставляете пользователя искать транзитивные зависимости вручную? ну типа у вас есть какой-нибудь api клиент с использованием guzzle, а guzzle нужной версии вы заставляете людей ставить?
А если ваша библиотека написана с использованием nullable, а у человека 7.0, он тоже об этом только опытным путем узнает?
Также этот инструмент позволяет использовать .env файлы, которые использует тот же docker compose для того, чтобы не пересобирать приложение во время разработки
Так что dotenv — это упрощение именно разработки для тех людей, где прод построен на энвах