вы когда контрибьютите в симфони или бандлы, вы как их тестируете?

делаете симлинк в vendor?

делаете симлинк в vendor?

Зачем?

Зачем?

чтобы проверить свой код, который лежит где-то в соседней директории

переводят его на flex

?

вы когда контрибьютите в симфони или бандлы, вы как их тестируете?

Насколько я мог понять тебя (а это не просто) тебе достаточно сделать composer install --prefer-source тогда у тебя в в проекте все vendors будут ставится с гитом. Ты сможешь прям в vendor/bundle-name/ править и коммитить

Насколько я мог понять тебя (а это не просто) тебе достаточно сделать composer install --prefer-source тогда у тебя в в проекте все vendors будут ставится с гитом. Ты сможешь прям в vendor/bundle-name/ править и коммитить

not bad

Насколько я мог понять тебя (а это не просто) тебе достаточно сделать composer install --prefer-source тогда у тебя в в проекте все vendors будут ставится с гитом. Ты сможешь прям в vendor/bundle-name/ править и коммитить

не оч удобно имхо

я обычно симлинки прокидываю

вроде на вебинаре ryan говорил что симлинки это тру

причем иногда даже в src, а не vendor

но могу ошибаться

у жабаскриптеров прикольно

вроде на вебинаре ryan говорил что симлинки это тру

линк если можно

npm link в папке пакета npm link <package_name> в проекте, куда хочешь воткнуть свой локальный

я обычно симлинки прокидываю

В чем плюс?

и у тебя автоматом симлинка на глобальный node_modules есть

В чем плюс?

в src? или вообще симлинки?

чтобы проверить свой код, который лежит где-то в соседней директории

Почему он у тебя в соседней?

симлинки - то, что можно спокойненько держать N проектов/бандлов разных и не бояться, что затрешь vendor

В чем плюс твоего решения с прокидываниями симлинков, в сравнении с тем, что предлагаю я (прямо в vendor контрибютить)

Почему он у тебя в соседней?

бо разделение на бандлы/либы)

о, нашел

https://www.youtube.com/watch?v=R6Os9vcWbXw

В чем плюс твоего решения с прокидываниями симлинков, в сравнении с тем, что предлагаю я (прямо в vendor контрибютить)

не оч удобно разрабатывать

В чем плюс твоего решения с прокидываниями симлинков, в сравнении с тем, что предлагаю я (прямо в vendor контрибютить)

ото выше описал но это зависит от целей - для "запилить быстрофикс в либу" подойдет и твой вариант

бо разделение на бандлы/либы)

А как это относится к фреймворку?

проще когда узкий скоуп)

но я не пробовал если че

А как это относится к фреймворку?

у нас ведь здесь не только симфоняшные штуки обсуждаются, а еще и всякое околосимфоняшное

у нас ведь здесь не только симфоняшные штуки обсуждаются, а еще и всякое околосимфоняшное

ну как, еще за котлин тут топим иногда

но я не пробовал если че

будешь пробовать - внимательно перепроверяй неймспейсики и куда какой симлинк, я с этим тупился не раз

Ну так и разрабатывать надо как либу обычную. Он же спросил как в фреймворк контрибьютить

там еще было "в бандлы"

и "как тестируете"

и "как тестируете"

В доке ж написано

Про бандлы

симлинки - то, что можно спокойненько держать N проектов/бандлов разных и не бояться, что затрешь vendor

не понимаю. Ты про обычные unix: ln -s ? Как это "успокаивает" тебя, и почему ты боишься трогать вендор? 1. Делаешь форк 2. Заставляешь ставить композер либу со своего форка, а не с пэкеджиста (2 строчки в композере) 3. Правишь прямо в вендор и там же тестишь (прям в вендор еще раз делаешь composer install и там же юниты гоняешь - это никак не мешает твоему проекту) 4. Коммитишь и пушишь (в свой форк) 5. Добавляешь в рут композер версию своего нового коммита (dev-master#COMMIT) Profit Ты не боишься за свой вендорс - можешь спокойно их сносить. У тебя сразу твой проект работает с твоим поправленным кодом. Ждешь когда примут твой ПР и спокойно отказываешься от своего форка >>>>будешь пробовать - внимательно перепроверяй неймспейсики и куда какой симлинк, я с этим тупился не раз И вот такой хни не будет

makes sense, спс

Добавлю: 5. Добавляешь в рут композер версию своего нового коммита (dev-master#COMMIT) Тут можно тыкнуть имя своей ветки - так можно будет еще и рут composer.json больше не трогать

я не спорю, что так тоже можно но 1. я еще не привил себе практику WIP-коммитов (хотя постоянно себе об этом напоминаю) 2. есть либы, которые я делаю для себя/проекта (обертки над другими и тд) - тут уж мне точно не сделать форк + она может быть вполне себе независимой от моего проекта (точнее, является) + см. 1

на самом деле это вкусовщина вполне возможно, что если мне понадобится сделать просто фикс в другую либу - я применю твой способ

Варик с prefer source хорош

не понимаю. Ты про обычные unix: ln -s ? Как это "успокаивает" тебя, и почему ты боишься трогать вендор? 1. Делаешь форк 2. Заставляешь ставить композер либу со своего форка, а не с пэкеджиста (2 строчки в композере) 3. Правишь прямо в вендор и там же тестишь (прям в вендор еще раз делаешь composer install и там же юниты гоняешь - это никак не мешает твоему проекту) 4. Коммитишь и пушишь (в свой форк) 5. Добавляешь в рут композер версию своего нового коммита (dev-master#COMMIT) Profit Ты не боишься за свой вендорс - можешь спокойно их сносить. У тебя сразу твой проект работает с твоим поправленным кодом. Ждешь когда примут твой ПР и спокойно отказываешься от своего форка >>>>будешь пробовать - внимательно перепроверяй неймспейсики и куда какой симлинк, я с этим тупился не раз И вот такой хни не будет

Топчик, аж лайкнуть захотелось

Ток лайков нема

О чем вы? Не проследил...Нооо могу сказать что make крутая штука)

Орнул

makes sense, спс

О чем вы? Не проследил...Нооо могу сказать что make крутая штука)

не понимаю. Ты про обычные unix: ln -s ? Как это "успокаивает" тебя, и почему ты боишься трогать вендор? 1. Делаешь форк 2. Заставляешь ставить композер либу со своего форка, а не с пэкеджиста (2 строчки в композере) 3. Правишь прямо в вендор и там же тестишь (прям в вендор еще раз делаешь composer install и там же юниты гоняешь - это никак не мешает твоему проекту) 4. Коммитишь и пушишь (в свой форк) 5. Добавляешь в рут композер версию своего нового коммита (dev-master#COMMIT) Profit Ты не боишься за свой вендорс - можешь спокойно их сносить. У тебя сразу твой проект работает с твоим поправленным кодом. Ждешь когда примут твой ПР и спокойно отказываешься от своего форка >>>>будешь пробовать - внимательно перепроверяй неймспейсики и куда какой симлинк, я с этим тупился не раз И вот такой хни не будет

сделал так как говоришь. удобнее

О чем вы? Не проследил...Нооо могу сказать что make крутая штука)

И что?

делаете симлинк в vendor?

да

да

тут уже более удобный вариант предложили

сча почитаю

не понимаю. Ты про обычные unix: ln -s ? Как это "успокаивает" тебя, и почему ты боишься трогать вендор? 1. Делаешь форк 2. Заставляешь ставить композер либу со своего форка, а не с пэкеджиста (2 строчки в композере) 3. Правишь прямо в вендор и там же тестишь (прям в вендор еще раз делаешь composer install и там же юниты гоняешь - это никак не мешает твоему проекту) 4. Коммитишь и пушишь (в свой форк) 5. Добавляешь в рут композер версию своего нового коммита (dev-master#COMMIT) Profit Ты не боишься за свой вендорс - можешь спокойно их сносить. У тебя сразу твой проект работает с твоим поправленным кодом. Ждешь когда примут твой ПР и спокойно отказываешься от своего форка >>>>будешь пробовать - внимательно перепроверяй неймспейсики и куда какой симлинк, я с этим тупился не раз И вот такой хни не будет

ммм.... я в пет прожекте просто репозиторий делаю

ну то есть композером делаю симлинк на пакет

а.... ты про форки

я про свои бандлы)

https://www.youtube.com/watch?v=R6Os9vcWbXw

Посмотрел до половины с линкэгем вижу что он использует линки но ни слова о рекомендациях

ишью по теме https://github.com/composer/composer/issues/601

????

https://github.com/symfony/symfony/pull/24746 хм

ERROR: S client not available

ммм.... я в пет прожекте просто репозиторий делаю

Видел ваши ответы на Тостере. Спасибо что помогаете новичкам!

Видел ваши ответы на Тостере. Спасибо что помогаете новичкам!

было время... уж год как туда не заходил

ну то есть композером делаю симлинк на пакет

Поясни, что-то я не могу понять, может мой вариант и не самый крутой.

Поясни, что-то я не могу понять, может мой вариант и не самый крутой.

https://getcomposer.org/doc/05-repositories.md#path

но с форками я обычно работаю по тупой схеме - клоню свой форк

как правило мне редко нужно в вендорах править, чаще просто глянуть как вышло

https://getcomposer.org/doc/05-repositories.md#path

о, тоже неплохо

да единственный минус в том что нужно коммитить все подряд

Получается, с точки зрения лишних телодвижений, composer path такой же composer update все-равно нужно делать (чтобы composer.lock подсосал коммит, и в случае пересоздания проекта у тебя ничего не упало) А с точки зрения командной разработки или CI\CD нужно дописывать клон репозитория в соседнюю папку по определенному пути - ну такое. Вариант с своим форком будет работать из коробки, у всех разрабов и на всех CI\CD

но ведь мы про локальное говорим

Ну вот и после этого я думаю зачем мне докер и кубернетес) Так он от такого избавляет

))))

Получается, с точки зрения лишних телодвижений, composer path такой же composer update все-равно нужно делать (чтобы composer.lock подсосал коммит, и в случае пересоздания проекта у тебя ничего не упало) А с точки зрения командной разработки или CI\CD нужно дописывать клон репозитория в соседнюю папку по определенному пути - ну такое. Вариант с своим форком будет работать из коробки, у всех разрабов и на всех CI\CD

там симлинк

ничего не надо дергать и ничего не надо обновлять

но это подходит ТОЛЬКО если у тебя пакет лежит прям в том же репозитории

ну то есть закоммичен

для форков не подходит

повторюсь - я этот вариант использую когда мне надо по быстрому протестить свою библиотеку или бандл (чаще бандл) в контексте живого проекта

но это подходит ТОЛЬКО если у тебя пакет лежит прям в том же репозитории

Ну, тогда да Просто есть еще вариант (композер будет хавать) положить либу ВНЕ репозитория - это тоже будет работать, с точки зрения композера. Минусы я уже описал.

Ну, тогда да Просто есть еще вариант (композер будет хавать) положить либу ВНЕ репозитория - это тоже будет работать, с точки зрения композера. Минусы я уже описал.

Мутил как то я с композером. Послал он меня на PSR

)))

Доброй ночи, господа и дамы (если есть)! С наступившим Новым годом! Собрался с силами перевести боевой проект с sf2.6 + bitbucket+ Magallanes (rsync) + stand-alone prod host на sf4 + gitlab + локальный CI + набор docker контейнеров (kubernets поверх VMware?) Перевод на sf4 отдельный крупный геморрой (с этим справлюсь и более менее понятно как). Интересует использование докера при разбивке sf4 приложения по нескольким контейнерам, оркестрация и автоматический деплой после прохождения тестов. Прошу поделиться опытом, лучшими практиками, подводными камнями и полезными ссылками. Заранее спасибо.

> Интересует использование докера при разбивке sf4 приложения по нескольким контейнерам типа контейнер с php, контейнер с воркерами и т.д.?

https://github.com/fesor/project-skeleton - можешь глянуть тут

для вдохновения, лучше не копипастить)

> Интересует использование докера при разбивке sf4 приложения по нескольким контейнерам типа контейнер с php, контейнер с воркерами и т.д.?

Да, не ли готового общепринятого решения или все «велосипедят» под себя ?

ну то есть, образ приложения ты будешь пилить по любому под себя, а все остальное берешь из docker hub

тут весь вопрос - что ты подразумеваешь под "велосипедить"

docker-compose, кубернетис - это уже не велосипедить

Нужен днс в котором хранятся адреса хостов, нечто вроде haproxy прокидывать на живой/менее нагруженный

Нужен днс в котором хранятся адреса хостов, нечто вроде haproxy прокидывать на живой/менее нагруженный

это есть в кубернетисе