composer remove

[AmdY]

Для приложений - да. Ну или в варианте 1 для skeleton. В варианте 2 смысла не вижу, опенсорсу для развития нужно тестирование новых версий.

Это ты ребятам делающим пакеты под laravel скажи, никакого версионирование и на новую версию перешли сразу вместе с выходом, плевать на BC. lock - наименее геморный вариант. Я сам не чураюсь по старинке всю папку вендоров класть в git, помню ещё времена когда гитхаб падал часто, а иногда на долго.

 

[fixxxer]

Ну пакеты делают разные ребята. Всякое бывает. Я вот половину вообще сразу в приватный репоз форкаю и правлю, потому что ад.

Папочку vendor это как-то жесть, зачем это говно в changesets. А вот миррор репозов - идея неплохая, надо будет сделать.

 

[Вурдалак]

Absinthe, так я не против composer.lock так какового, естественно. Коммитить его нужно. Но иметь его сразу же в symfony-stadard для меня странно. Я там обычно еще кучу зависимостей добавляю и т.д., я 100% напишу просто composer update, обновится всё, смысл в изначальном composer.lock практически отсутствует.

 

[Absinthe]

Absinthe, так я не против composer.lock так какового, естественно. Коммитить его нужно. Но иметь его сразу же в symfony-stadard для меня странно. Я там обычно еще кучу зависимостей добавляю и т.д., я 100% напишу просто composer update, обновится всё, смысл в изначальном composer.lock практически отсутствует.

Я пример привел: http://phpclub.ru/talk/threads/composer-remove.79758/#post-720136

 

[Вурдалак]

Я пример привел: http://phpclub.ru/talk/threads/composer-remove.79758/#post-720136

Да, я понял твой пример. На чистой установке просто я готов рискнуть и сломать приложение. Я ничем не рискую, кроме как «о, разработчики Doctrine опять сломали BC, ололо».

 

[MiksIr]

2) берется последняя версия из ветки, gentoo/arch way. Лок-файла нет. Для публичного app skeleton на гитхабе самое то. Свежак. При существенном покрытии тестами риски небольшие.

А о каких тестах речь? Если о юнит тестах своего приложения, то там же внешние библиотеки как раз не нужно тестировать?

 

[Absinthe]

Да, я понял твой пример. На чистой установке просто я готов рискнуть и сломать приложение. Я ничем не рискую, кроме как «о, разработчики Doctrine опять сломали BC, ололо».

Приложение в ответе за свои зависимости.

 

[Вурдалак]

Если вспомнить, что даже некоторые самые популярные фреймворки .lock в репозитории не держат... Те, которые хипстерские.

Кстати, апну: https://github.com/symfony/symfony-standard/blob/2.7/composer.lock — c 2011 года.

 

[hell0w0rd]

Кстати, апну: https://github.com/symfony/symfony-standard/blob/2.7/composer.lock — c 2011 года.

это приложение, а не фреймворк. Ну точнее база/скелет для приложения

 

[Вурдалак]

это приложение, а не фреймворк. Ну точнее база/скелет для приложения

Именно про это и идёт речь. composer.lock в symfony/symfony иметь смысла не будет.

 

[Absinthe]

Именно про это и идёт речь. composer.lock в symfony/symfony иметь смысла не будет.

А если я использую фреймворк без скелета?
Мне будет неприятно его поставить и обнаружить, что он сломан.

К тому же я имел ввиду Ларавел, в котором .lock убрали как раз из скелета за неделю перед релизом. В бета-версии он был.

 

[Вурдалак]

А если я использую фреймворк без скелета?

Каким образом? Напишешь "require": {"symfony/symfony": ...}? И каким образом composer.lock внутри symfony/symfony тебе поможет? composer.lock оказывает эффект, только если он внутри твоего проекта.

 

[Absinthe]

Каким образом? Напишешь "require": {"symfony/symfony": ...}? И каким образом composer.lock внутри symfony/symfony тебе поможет? composer.lock оказывает эффект, только если он внутри твоего проекта.

А тут я что-то не подумал