После пяти лет разработки представлен (https://seld.be/notes/composer-goes-gold) первый стабильный релиз проекта Composer 1.0.0 (https://getcomposer.org/), в рамках которого развивается менеджер для установки зависимостей в проектах на языке PHP. Composer позволяет определить какие библиотеки функций необходимы для работы проекта, после чего берёт на себя работу по установке недостающих зависимостей и обновлению новых версий. Доступные для установки библиотеки размещены в репозитории Packagist (https://packagist.org/), который насчитывает более 92 тысяч пакетов. Код Composer написан на PHP и распространяется (https://github.com/composer/composer) под лицензией MIT.Проект наследует многие идеи пакетных менеджеров npm (https://npmjs.org/) и bundler (http://bundler.io/), используемых в сообществах разработчиков Node.js и Ruby. Composer позиционируется как система установки зависимостей, а не пакетный менеджер, так как оперирует пакетами в привязке к конкретным проектам, устанавливая зависимости в локальные директории этих проектов (имеется режим глобальной установки пакетов в систему для нескольких проектов, но он не применяется по умолчанию).
Поддерживается несколько каналов доставки обновлений: по умолчанию предлагается установка стабильных выпусков библиотек, но также имеется возможность использования экспериментальных обновлений (alpha/beta) и снапшотов (срезы находящейся в разработке кодовой базы), которые полезны при организации тестовых сборок в системах непрерывной интеграции.
URL: https://seld.be/notes/composer-goes-gold
Новость: http://www.opennet.me/opennews/art.shtml?num=44214
>>Проект наследует многие идеи пакетных менеджеров npm
>npmЭтот не тот, который из-за паники админов, кретинизма обладателя торговой марки и психов разработчика чуть раком не поставил весь JavaScript мир?
Причём тут сам пакетный менеджер?
В падении самолетов виновата гравитация. При чем здесь пилоты, техники и террористы непонятно. <сарказм>
Не вижу никакой связи в вашей аналогии.
Равняться на npm, который писали феерические алени -> нутыпонел.
очевидно, эту проблему учтут при разработке, поэтому она не должна возникнуть.
не очевидно
Очевидно, форумным экспертам лучше знать, чем разработчикам. Разработчики же не сидят по форумам в рабочее время.
Проблему копирастических проституток в администрации проекта решат при разработке ПО? Вот это новость!
> чуть раком не поставил весь JavaScript мир?что значит "чуть"?
Уже несколько лет пользуюсь а он все это время оказывается был нестабильным.
Сотни мб памяти(до 4гб доходит), часы работы на крупном проекте(без выключенного сборщика мусора).
Это назвать стабильным язык не поворачивается.
PS, прежде чем кудахкать попробуйте поставить akeneo crm например, и собрать.
Мне в свое время на вопрос как же его собрать на микро инстансе если там 2гб памяти не достаточно и работает сутки ответили что никак, такова суть компоста. Поделка детей.
Почитай про деплой.
Прочитал.
Деплой - развертывание.
> Почитай про деплой.Да это все отлично, все мы умеем и есть ci и cd и эту беду кое-как можно обойти. Да и проект с нуля не каждый день разворачивается.
Ты скажи мне, поясни, почему такая простая и примитивная задача решается с такими диким расходом времени и ресурсов. Как и чем это можно оправдать, какими "современными способами разработки" и "молодой командой" это вся можно пояснить.
Святые угодники, да если-бы в питоне pip по часу джанго ставил-бы то за неделю парни напакостили бы что-то более рабочее. То что компост живет в мире пхп и им еще кто-то гордится просто чудовищно.
Собрать? Пхп?
> Собрать? Пхп?Да какое пхп. Нет, выполнить свои прямые обязанности, стянуть в папку зависимости для проекта. Это два десятка поганых архивов по хттп выкачать, понимаешь? Два десятка!
2гб памяти МАЛО БЛ! ЧАСЫ ты понимаешь, часы работы!
> Собрать? Пхп?Вообще еслиб мне кто-то сказал про такое, я в тупую не поверил-бы.
Пхпешники веселые ребята если пользуются этим каждый день. Это тупо позор.
херню какую-то несешь. 23 зависимости в композере и все ок.
> херню какую-то несешь. 23 зависимости в композере и все ок.Да все ок, поставь акенео. Просто поставь. Жду тебя через пару часов с фидбеком.
Конкретнее? Скачал отсюда архив https://www.akeneo.com/download/ запустил composer install. Все зависимости уже есть.
Создать пустой проект и добавить в composer пакет "akeneo/pim-community-dev"?
> Конкретнее? Скачал отсюда архив https://www.akeneo.com/download/ запустил composer
> install. Все зависимости уже есть.
> Создать пустой проект и добавить в composer пакет "akeneo/pim-community-dev"?О пустом речь шла, само собой.
по памяти да, много жрет, на 64 битной win7 сожрало ~1гб.
по времени заняло чуть больше 10 минут. точно не засек 11-12 где-то.
может у тебя интернет медленный просто?
P.S. да, запускал на php7
вопрос всего треда: почему даже сраный gradle работает быстрее и ест меньше памяти?
на дев серваке собирай
деплой файлы
в чем проблема?
> на дев серваке собирай
> деплой файлы
> в чем проблема?лол, читай выше.
А в чём проблема собрать на чердаке с SSD и 32 Гб памяти, а на микроинстанс деплоить уже готовые файлы?
Да никаких проблем. Точно также как никаких проблем, чтобы достичь того же результата банальной ручной установкой тарболов, при этом никакого компоста и отдельной машины с ssd+32gb вообще не нужно.
А поскольку для человека, считающего установку тарболов банальной, все равно, где читать о зависимостях проекта - в README или в конфиге компоста, получается, что проблемы в существующей ситуации, когда для описания зависимостей используется компост, действительно нет.
Прочитай в документации, когда надо запускать composer install, а когда composer update, и что именно они делают.composer install не кушает почти нисколько.
А когда менеджер зависимостей и менеджер пакетов для менеджеров пакетов и менежеров зависимостей напишут?
Это настолько нeнyжно, что даже нeнyжно. А те, кто его используют - деграданты. Потому что нормальный проект использует максимум 2-3 зависимости, которые вполне можно подтянуть руками, а пользователи композера и того не осиливают.
Вы сильно ошибаетесь.
Использование пакетных менеджеров для таких языков как PHP и javascript дает очень большую отдачу:
1. С точки зрения разработчика. Сборка проекта скелета проекта осуществляется быстро. Писать, зная каждую зависимость, получается быстро и просто. Дестких болезней не встречается.
2. С точки зрения менеджера проекта/фрилансера и т.п. Собранный один раз проект, без последующей поддержки со стороны создателя является мертвым грузом: никто в здравом уме отсурсенный проект не станет развивать сам (посмотрите, какие и сколько фреймфорков нужно знать, чтобы устроиться PHP/js программистом? Да, да, да, досканальные знания оригинального js и понимание подходов разработки на нем никому не нужны, потому что их никто не применяет)
3. С точки зрения заказчика. Получаем за небольшие деньги проект с минимумом фукциональности. Никаких людей в штат не надо - полностью все обслуживание на создателе. Особо начнет "хамить" - есть сотня других, которые с удовольствием перепишут все, почти за даром, лишь бы получить сливки с развития/раскрутки и т.п.Все в выигрыши. И да, к разработке вся эта магия не имеет никакого отоншения. Это как борд на дороге повесить или кассу оснастить.
> 1. С точки зрения разработчика. Сборка проекта скелета проекта осуществляется быстро. Писать, зная каждую зависимость, получается быстро и просто. Дестких болезней не встречается.Как часто это требуется? Если речь идет о одном проекте в месяц или два, то к разработке они отношения не имеют. Это конвеерное клепание. Нет проработки архитектуры, просто вытряхиваются запчасти, обвязываются кое-как резинкой и кидаются в сторону заказчика.
Как я уже говорил, это деградация разработки. И Композер ориентирован на эту нишу.
> И да, к разработке вся эта магия не имеет никакого отоншения. Это как борд на дороге повесить или кассу оснастить.
Собственно о том и речь. Для конвеерщиков. Которые не думают как реализовать то или иное с заделом на расширение, просто лепят здесь и сейчас, отдают заказчику и навсегда забывают о проекте. Для тех, кто обвешивает страницы десятками jQuery-плагинов из которых, от силы, по одному методу требуется использовать.
Ты не в теме абсолютно. https://github.com/symfony/symfony/blob/master/composer.json пример конвеерного проекта по твоему? наоборот, менеджер зависимостей позволяет не писать require/include с перечислением кучи возможных зависимостей, а выкачать сторонний пакет, и сразу его использовать.
Мда. Получается, разработчики вообще не следят за тем, что тянут в проект. Ни чейнджлоги почитать, ни проверить совместимость с существующим кодом. Что-то вроде функции отката в винде - половина системы старая, половина новая, и все такое неконсистентное, кое-как работающее (а юзеру большего и не надо, он счастлив самим фактом того, что избежал переустановки).
> Мда. Получается, разработчики вообще не следят за тем, что тянут в проект.Для этого есть semver. Если ты указал в composer версию 1.0.* то ты гарантированно не поломаешь обратную совместимость.
Хочешь сидеть без обновлений укажи конкретную версию типа 1.0.4
Ты привел пример, который устроил бы меня, но этот пример показывает, что смысла в сабже нет. Один раз скачал и больше не обновляешься. И для этого отдельную софтину писали (которую, как писали выше, вообще разносит до использования нескольких гигабайт оперативки)?При этом, если представить, что остальные в отличие от меня пользуются постоянным обновлением модулей, остается в силе сказанное мной выше о неконсистентности на которую всем покласть, потому что избавление от ручной распаковки модулей для них важнее чем консистентность и общая протестированность кода сайта.
Ай, ты просто уперся как баран)
Я тебе говорю как писавший еще на пхп 4. Composer реально упрощает работу. Тем более что сейчас все нормальные проекты пишутся исключительно под него, и руками ты их так просто не поставишь.
Не нужно отставать от современных тенденций.
> Тем более что сейчас все нормальные проекты пишутся исключительно под негоТак только вышла первая стабильная версия. Ты или обманываеш или такие "нормальные" проекты.
>> Тем более что сейчас все нормальные проекты пишутся исключительно под него
> Так только вышла первая стабильная версия. Ты или обманываеш или такие "нормальные"
> проекты.Используют его уже давно в продакшене, хз почему composer решил именовать себя alpha-beta так долго.
Да нет, просто я тоже начинал с 4-го, и говорю по своему опыту. А что касается тенденций, стороной меня они не обходят, но в случае с сабжем я предпочту ручной контроль автоматизации.> Тем более что сейчас все нормальные проекты пишутся исключительно под него, и руками ты их так просто не поставишь.
"Компьютер позволяет решать задачи, которые до его изобретения не существовали" - то же и с Композером. Я по-прежнему не имею проблем с ручной подборкой модулей. Потому что использую из обдуманно и считанные единицы, а не тяну в проект что попало.
> Да нет, просто я тоже начинал с 4-го, и говорю по своему
> опыту. А что касается тенденций, стороной меня они не обходят, но
> в случае с сабжем я предпочту ручной контроль автоматизации.
>> Тем более что сейчас все нормальные проекты пишутся исключительно под него, и руками ты их так просто не поставишь.
> "Компьютер позволяет решать задачи, которые до его изобретения не существовали" - то
> же и с Композером. Я по-прежнему не имею проблем с ручной
> подборкой модулей. Потому что использую из обдуманно и считанные единицы, а
> не тяну в проект что попало.Ну, как минимум, это говорит что ты не работал с современными php фреймворками. Вероятно, стек задач - это проекты на джумле/вордпрессе/друпале/битриксе... Отсюда и такие позиции нездоровые.
"Позиции нездоровые" оттого, что пользуясь гентой, всегда после обновлений что-то отваливается (не потому что не умею пользоваться, просто это неизбежное зло от удобства пользования дистрибутивом). В Композере аналогичный принцип. Но стабильность проектов в интернете мне (и клиентам) важнее стабильности системы дома. И да, проекты у меня на Yii и Kohana.
Тем увлекательнее будет знакомство с Yii2)
P.S. а еще когда нибудь познакомишься с composer.lock и composer install и не будешь писать глупости про стабильность)
Gentoo собирает программы из портов(!!). Причём же здесь composer? Он скорее больше похож на debian, где вы тянете готовые пакеты.
Да, в Gentoo тоже можно подключить репозиторий с бинарными пакетами (хотя многие об этом и не знают), но, как я понимаю, речь не об этом.
> Gentoo собирает программы из портов(!!).Не из портов, а из портков (которые на лямках).
Речь о том, что обязанность тестировать работоспособность сайта и операционной системы в том и другом случае ложится на пользователя, который произвел обновление, но в случае ручного прощупывания каждого обновляемого модуля - контроля больше.
Не ложится она на пользователя. Для контроля консистентности достаточно composer.lock таскать вместе с проектом(в git к примеру), а при развёртывании использовать composer install и будет всё зафиксировано в точности таким как в тот момент когда разработчик последний раз писал composer update. А обновление и тестирование новых зависимостей уже будет проводить разработчик.
Тогда зачем этот Композер вообще нужен? Лишняя сущность.
Интересу ради. Вы в репозитории код как храните? С композером мне понятно. Положил composer.json с прописанными зависимостями и всё. Потом другой программист сделал "composer install" и получил развёрнутый проект.
Да все стандартно, в git. Но снова обращу внимание, что зависимостей у меня минимум, что попало в рот не тащу. Другие программисты клонируют сразу готовый проект.
Да какой интерес, чел просто застрял на php 5.2 (в лучшем случае), это же видно, и просто еще не освоил современные подходы в php программировании.
Ты кроме как "это прикольно" так и не донес в чем смысл сабжа.
> Ты кроме как "это прикольно" так и не донес в чем смысл
> сабжа.Да вроде как и не собирался. Довольно быстро стал понятен уровень знаний, и упертости, что делает бессмысленным донесение очевидных преимуществ автозагрузки и менеджмента зависимостей.
Я тебе про принцип KISS, а ты мне про уровень знаний. Я тебе про то что не использую 100500 зависимостей, а ты мне про то что это просто, модно и удобно если ввести 100501-ю - Композер. Не надо считать себя опытнее других.
> Я тебе про принцип KISS, а ты мне про уровень знаний. Я
> тебе про то что не использую 100500 зависимостей, а ты мне
> про то что это просто, модно и удобно если ввести 100501-ю
> - Композер. Не надо считать себя опытнее других.Я тебе про автозагрузку и менеджмент зависимостей, а ты мне по то что ты любишь велосипедить.
Хранить в репозитории не свой код от которого зависит ваш код не имеет смысла -- это плохой тон. Вы же работаете над своим проектом. Хранить, к примеру, сам фрэймворк или части, типа ORM, смысла нет.
Композер позволяет положить в репозиторий только один файл, в котором описаны зависимости от нужных версий нужных библиотек. При развёртывании он подтянет всё, что требуется и положит туда, куда требуется.
Какие проблемы с обновлением? Вы пишите свой код. Решите, что нужно обновить его для работы с новыми библиотеками -- перепишете код и обновите версии в зависимостях композера.
Кроме того, есть сценарий, при котором вы, начиная новый проект, подтягиваете любимый ORM, любимый шаблонизатор и начинаете разработку.
Спасибо, доходчиво. И смысл имеет. Но, тем не менее, хочется сказать, что его поголовное использование вовсе не из-за желания следовать хорошим практикам программирования, которые вы описали, а не более чем хипстерская мода. Вон товарищ Геморрой выше не смог внятно объяснить, практически все его аргументы сводились к тому, что круто, модно и молодежно. И об архитектуре думать не надо - накидал все в одну кучу и пользуешься.
> Это настолько нeнyжно, что даже нeнyжноЭто настолько толсто, что даже скушно.
Composer V1.0.0 Anniversary Gold* Edition
http://www.ebay.co.uk/itm/Composer-V1-0-0-Anniversary-Gold-E...
какой то фейк
чем это лучше git submodue udpate --init --recursive
?
сколько лет пишу на php не знаю нафига юзать что-то типа этого композера
Тяжело быть PHP пограммистом