Компоузер это кто – Объясните, что такое за профессия компоузеры и чем они занимаются? — Вебджем.рф

Содержание

Кто такой композер? | Simpals

Тот, кто умеет позировать с компотом? Или краткое обозначение композитора? А может человек, который работает за компом у озера? Нет =) Композер (или же compositing artist) — это специалист по композитингу =) Итак… Композер — это тридешник, т.е. человек, который занимается 3D-графикой, и отвечает за финальную картинку. Т.е. кто-то занимается созданием 3D-моделей, задает этим моделям «кости», заставляет модели двигаться, кто-то создает спец-эффекты, задний фон, а кто-то складывает все-все-все слои, в которых работали другие тридешники, и выдает ту картинку, ради которой мы и ходим в кинотеатры. И делают это композеры.

Compositing breakedown from Denis Kiriliuc on Vimeo. А еще композер – это человек, на которого остальные тридешники, обычно, полагают большие надежды. Связаноэто с тем, что композитинг – это завершающая стадия 3D-производства, и поэтому все недочеты (сделанные на предыдущих стадиях) исправлять приходится именно им. Но зато именно композеры часто за своими спинами слышат «Уау, очень круто получается!»

Bob_1

до

Bob_2

после

Такие специалисты часто востребованы на телеканалах и в производстве рекламы (это помимо киноиндустрии). И вот почему. Многие уверены, что композеры – это люди, которые работают только с цветом или просто склеивают финальную картинку из слоев. Но на самом деле, композер в одиночку может значительно преобразить видеоряд. Ну что, вы ведь уже захотели стать супер-мега-крутым композером? Ну тогда добро пожаловать в Школу Монстров на курсы по композитингу! Знакомьтесь.

Денис Кирилюк — специалист, под чьим чутким наблюдением и руководством вы проведете 2 увлекательных месяца. «Я по образованию не композер, а дипломированный финансист. Но по специальности никогда не работал. Понял, что не мое это. В свое время меня направил друг, который занимался дизайном интерьера, подкинул книгу по After Effects, и я ею увлекся. Ненадолго, правда. Как дочитал книгу, бросил и забыл (от ред. — забил). А на третьем курсе университета вспомнил о композитинге, когда понял, что финансы и страхование — не мое. Университет решил отложить, но потом, конечно, доучился. Поэтому, когда увидел в интернете вакансию «compositing artist», без раздумий написал CV. Но не потому, что мечтал работать композером, просто программа, которая была указана в вакансии, была мне известна, ее я и учил по книге. И меня пригласили на собеседование. Это был Simpals, они (спасибо им большое!) досмотрели до конца (!!!) мои работы, и даже согласились взять меня на обучение. И вот так со временем, изо дня в день, что-то начало получаться. Хотя, сначала вообще не верилось, что смогу что-то сделать. Это как учиться отжиматься или бегать. Отжался 20 раз и думаешь, что ты крутой, а рядом парень 100 раз делает. И ты думаешь, что никогда таким не станешь. Но это не правда. На сегодняшний день я работаю над 3D-проектом, собираю мультфильм — очередную серию про приключения смерти-неудачника по имени Джи.

Сергей Кириллов и Денис Кирилюк (ведущие композеры анимационной студии Simpals) на вручении награды за лучший мультфильм на фестивале Deciminute (Италия) Так что такое композ? Это наложение различных слоев видео друг на друга, или наложение видео на ранее сгенерированную картинку в 3D. Это может быть цветокоррекция, добавление каких-то эффектов к снятому видео, сюда же входит целый раздел motion graphics, анимация текста, различных элементов и т.д. Сам композитинг делится на несколько подразделений: — клинап — зачистка картинки, это когда вам нужно убрать из картинки попавшие в кадр лишние объекты: отражения в зеркале, тросы, на которых летают главные герои, или любые другие объекты, которые режиссер решил убрать из кадра. — ротоскоп — работа с масками, является частью клинапа. С помощью ротоскопа мы можем вырезать какой-то элемент и вставить его в совершенно новую локацию: мотоциклист едет по лесу, а нам нужно, чтобы он ехал по пустыне. в общем, очень сложная и кропотливая работа. — кеинг — отделение персонажа или объекта от зеленого экрана. Но о всех тонкостях работы вы узнаете на курсах в Школе Монстров.

Что такое composer и зачем он нужен?

Если вы хотите научиться серьезно работать с языком программирования PHP, то вам нужно обязательно освоить такой инструмент как Composer.

Давайте разберемся в этом видео, что такое Composer и зачем этот инструмент вам может пригодиться.

Composer — это просто программа, которая работает «в связке» с языком программирования PHP.

Без PHP использование composer просто не имеет смысла.

Официальная ссылка на сайт composer:

https://getcomposer.org

Composer — это консольная программа. Это означает то, что у этой программы нет какого-либо графического интерфейса. Управлять этой программой мы с вами можем набирая команды в терминале операционной системы.

В каждой операционной системе есть терминал или консоль. Это некое окно, в котором можно вводить команды с помощью клавиатуры.

Composer — это та программа, которая работает через консоль (терминал).

Графических элементов по которым можно покликать и повзаимодействовать в этой программе нет.

Composer — это менеджер зависимостей для языка программирования PHP.

Если вы работали с фронтенд проектами, которые написаны на языке программирования Javascript, на HTML, на CSS, вам, возможно, приходилось уже встречаться с таким понятием как менеджер пакетов. Это такие программы, как npm или yarn.

Composer — это менеджер зависимостей, который написан именно для языка PHP, в отличии от npm и yarn.

Что же такое «зависимость»? Что же это за менеджер, который управляет зависимостями.

Предположим, мы создаем какой-нибудь php-проект. В этом проекте будут какие-то файлы. В какой-то момент времени развития этого проекта мы понимаем, что писать весь код самостоятельно — это не самая лучшая работа. Есть решения, которые написаны уже за нас и можно просто их применить в нашем проекте.

Такие решения называются библиотеки, зависимости или пакеты.

К примеру, вы разрабатываете какой-либо Интернет магазин и вам нужно написать какой-то модуль, который бы отправлял сообщение на email пользователя. Написать такой модуль с нуля довольно трудно.

Но, к счастью, уже есть готовые решения, которые могут решить эту задачу намного проще и быстрее.

Например, есть такая библиотека как swiftmailer. Подключив ее к проекту мы получаем все необходимые классы и методы для работы с email.

Composer — это менеджер для подключения и управления этими сторонними библиотеками или пакетами в вашем PHP-проекте.

Еще его называют пакетный менеджер.

Composer управляет этими пакетами, чтобы они подключились и хорошо работали.

Конечно, вполне возможно обойтись и без composer для того, чтобы создавать php-проекты. Можно подключить все библиотеки вручную и все будет отлично работать.

Зачем же в таком случае нужен composer?

Много рутинных операций при установке.

Нужно производить настройки, подстраивать автозагрузку компонентов и.т.д.

2. Трудность в обновлении библиотек на новые версии.

Библиотеки имеют такое свойство расширяться и обновляться. Если вы вручную будете обновлять каждый пакет в вашем проекте, это работа довольно трудная и большая.

В composer для обновления пакетов достаточно выполнить одну команду и все пакеты успешно обновляться.

3. Одна библиотека может требовать для своей работы другую, другая третью и.т.д.

В итоге, может получаться ряд зависимостей, которые вы должны подключать.

Бывают такие библиотеки, которые для своей работы могут требовать десяток и даже сотни других библиотек.

Если это все скачивать и подключать вручную на это может уйти месяцы работы.

В случае с composer вы просто выполняете команду установки какой-либо библиотеки и он уже автоматически подключит все необходимые для этого другие библиотеки.

Пожалуй, это самое важное преимущество почему стоит использовать composer в своей работе.

4. Трудность переноса проекта на рабочий сервер из-за большого объема библиотек.

В вашем проекте код самого проекта может занимать всего десятки килобайт, а библиотеки, которые подключены к этому проекту могут занимать сотни и 10-ки сотен мегабайт.

Для того, чтобы перенести изменения на рабочем сервере, вам каждый раз нужно будет передавать такой большой объем данных.

Решение этой проблемы с composer довольно простое. В программе composer есть файл настроек, который вы устанавливаете на вашем домашнем компьютере и файл настроек, который вы устанавливаете на удаленном компьютере.

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

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

Конечно, создавать проекты без composer на PHP можно, но нужно ли вам это?

Если пользоваться любым современным фреймворком (symfony, laravel), то без composer вообще не обойтись.

Такой вот важный инструмент. Очень рекомендую освоить его работу, чтобы повысить свой уровень знаний и продвинуться в веб-программировании.

Кто такой композер? — MultTov Новости Анимации

ЭТО ЗАВЕРШАЮЩАЯ СТАДИЯ В ПРОЦЕССЕ ВИЗУАЛЬНОГО ПРОИЗВОДСТВА на этапе постпродакшена. Композеры ответственны за финальный продукт: анимационный ролик, фильм, рекламное или телевизионное видео, игру и так далее — за то, чтобы не было никаких визуальных ошибок и помарок и всё выглядело опрятно и сбалансировано.

Сергей Шуппо

lead compositing artist, студия Main Road|Post

КОМПОЗЕРЫ ВИЗУАЛЬНЫХ ЭФФЕКТОВ (от англ. compositing — компоновка, сборка)вносят последний штрих в изображение при создании компьютерной графики. Они собирают кадр (кадр/шот — одна смена камер, из них собираются большие сцены) в единое целое, складывают множество CG-слоёв, интегрируют в съёмочный материал элементы, которые невозможно было бы снять, убирают из шотов всё то, чего там не должно быть. Суть их работы — сделать финальный кадр красивым и «настоящим», чтобы всё смотрелось гармонично, чтобы зритель верил в то, что он видит.

Как и большинство профессий в области VFX, композ делится на несколько составляющих. В нашей студии, как правило, ребята целиком проделывают работу над своими шотами, но в основном есть определённые градации. Compositing artist’ом, или композером, человек становится не сразу. Самая первая ступень на пути к профессии композера — это ротоскоп (маскирование). Практически все шоты в кино требуют ротоскопа, то есть отделения от фона конкретного объекта, получения его маски.

Допустим, в кадре на переднем плане бегут люди, а за ними какое-то строение, которое нужно поджечь. Чтобы это сделать, нужно отделить людей от общего фона, получить их маски, а потом уже спокойно добавлять огонь, дым, искры. Маскирование — самая базовая задача, она не требует высокохудожественного подхода. Обычно этим занимаются ребята, которые только начинают путь композера.

ВТОРАЯ СТУПЕНЬ — это клинап (clean-up). Задача клинапера убирать из кадра всё лишнее, обычно это тросы, на которых подвешивали героев, затирка отражений(часто в стёклах любит отражаться съёмочная группа) и многое другое. Клинапер учится собирать картинку из кусков, восстанавливать те места, из которых удаляются ненужные участки. В фильме «Сталинград», например, у нас был очень непростой шот, в котором два танка переезжали через забор, крушили его и двигались дальше — вернее, должны были двигаться дальше, но один танк заглох. Его пришлось затереть, а после добавить полностью компьютерный танк. Работа эта уже не такая простая, требует элементов творчества.

ТРЕТЬЯ СТУПЕНЬ — кеинг, процесс отделения персонажей или объектов от зелёного/синего фона. Порой кей используют для получения масок, о которых говорилось в первой ступени. Позиция специалиста по кеингу очень спорная, её можно отнести, скорее, к составляющей композитинга, но, например, часть наших ребят (и я сам) начали кеить раньше, чем композить.

И ВОТ СЛЕДУЮЩАЯ СТУПЕНЬ — композер, правда, начинающий. Человек уже умеет резать маски, умеет клинапить, делает это уверенно. На данном этапе пробует собирать простые шоты, которые не требуют большого багажа знаний и умений. Композеры, которые проработали над несколькими проектами и накопили достаточно опыта, вырастают в лид-композеров (lead compositing artist). Они отвечают за пока ещё просто композеров, которые в будущем также могут вырасти до лидов. Дальше уже идут сиквенс-супервайзер, супервайзер в студии, супервайзер на площадке и VFX-супервайзер целого проекта.

Дарья Абрамова

21 совет по эффективному использованию Composer / Mail.ru Group corporate blog / Habr

Хотя большинство PHP-разработчиков умеют пользоваться Composer, не все делают это эффективно или лучшим возможным образом. Поэтому я решил собрать советы, которые важны для моей повседневной работы. Большинство из них опираются на принцип «От греха подальше»: если что-то можно сделать несколькими способами, то я выбираю наименее рискованный.

Совет № 1: читайте документацию

Я серьёзно. Документация у него замечательная, и несколько часов чтения сэкономят вам кучу времени в долгосрочной перспективе. Вы удивитесь, как много всего умеет делать Composer.

Совет № 2: различайте проект и библиотеку

Важно знать, что вы создаёте — проект или библиотеку. Каждый из вариантов требует своего набора методик.

Библиотека — это многократно используемый пакет, который нужно добавлять в качестве зависимости. Например, symfony/symfony, doctrine/orm или elasticsearch/elasticsearch.

Проект обычно представляет собой приложение, зависящее от нескольких библиотек. Обычно он не используется несколько раз (никакому другому проекту он не понадобится в качестве зависимости). Характерные примеры: сайт интернет-магазина, система поддержки пользователей и т. д.

Дальше в советах я буду переключаться между библиотекой и проектом.

Совет № 3: используйте для приложения конкретные версии зависимостей

Если вы создаёте приложение, то используйте для определения зависимости как можно более конкретный номер версии. Если нужно проанализировать YAML-файлы, то определяйте зависимость, например, так: "symfony/yaml": "4.0.2".

Даже если библиотека следует правилам семантического версионирования (Semantic Versioning), в минорных и патчевых версиях всё же могут возникать нарушения обратной совместимости. Допустим, если вы используете "symfony/symfony": "^3.1", то что-то устаревшее в 3.2 сломает ваши тесты. Или в PHP_CodeSniffer окажется исправленный баг, и в вашем приложении будут обнаружены новые ошибки форматирования, что снова может привести к сломанной сборке.

Обновляйте зависимости обдуманно, а не импульсивно. Подробнее об этом мы поговорим в одном из следующих советов.

Возможно, это кажется чрезмерным, но внимание к версиям зависимостей не даст вашим коллегам неосмотрительно обновить все зависимости при добавлении в проект новой библиотеки (которую вы могли пропустить при ревизии кода).

Совет № 4: для зависимостей библиотек используйте диапазоны версий

Если вы делаете библиотеку, то определяйте самый возможный диапазон версий. Если создаёте библиотеку, использующую библиотеку symfony/yaml для YAML-разбора, то запрашивайте её так: "symfony/yaml": "^3.0 || ^4.0"

Тогда ваша библиотека сможет использовать symfony/yaml из любых версий Symfony с 3.x по 4.x. Это важно, поскольку данное ограничение распространяется и на приложение, которое обращается к вашей библиотеке.

Если есть две библиотеки с конфликтующими требованиями (одной, к примеру, нужна ~3.1.0, а другой ~3.2.0), то будет сбой при установке.

Совет № 5: в приложениях нужно коммитить composer.lock в Git

Если вы создаёте проект, то нужно коммитить composer.lock в Git. Тогда все — вы, ваши коллеги, ваш CI-сервер и рабочий сервер — будут использовать приложение с одинаковыми версиями зависимостей.

На первый взгляд этот совет кажется излишним. Вы уже выбрали конкретную версию, как в совете № 3. Но ещё существуют зависимости ваших зависимостей, которые не связаны этими ограничениями (например, symfony/console зависит от symfony/polyfill-mbstring). Так что без коммита composer.lock вы не получите такой же набор зависимостей.

Совет № 6: в библиотеках кладите composer.lock в .gitignore

Если вы создаёте библиотеку (назовём её acme/my-library), то не нужно коммитить файл composer.lock. Это никак не влияет на проекты, использующие вашу библиотеку.

Допустим, acme/my-library использует monolog/monolog в качестве зависимости. Если вы закоммитили composer.lock, то все, кто разрабатывает acme/my-library, будут использовать более старую версию Monolog. Но когда вы закончите работу над библиотекой и используете её в реальном проекте, может быть установлена более новая версия Monolog, которая окажется несовместимой с вашей библиотекой. Но раньше вы не заметили этого из-за composer.lock!

Лучше всего класть composer.lock в .gitignore, чтобы случайно не закоммитить.

Если хотите быть уверены в совместимости библиотеки с разными версиями её зависимостей, читайте следующий совет!

Совет № 7: запускайте сборки Travis CI с разными версиями зависимостей

Совет относится только к библиотекам (потому что для приложений вы используете конкретные версии).

Если вы собираете open-source библиотеку, то, вероятно, запускаете сборки с помощью Travis CI. По умолчанию Composer устанавливает последние возможные версии зависимостей, допускаемые ограничениями в composer.json. Это означает, что для ограничения зависимости ^3.0 || ^4.0 сборка всегда будет использовать последнюю версию релиза v4. И поскольку версия 3.0 никогда не тестировалась, библиотека может оказаться несовместимой с ней, что опечалит пользователей.

К счастью, в Composer есть переключатель --prefer-lowest для установки самых старших из возможных версий зависимостей (его нужно использовать вместе с --prefer-stable для предотвращения установок нестабильных версий).

Обновлённая конфигурация .travis.yml может выглядеть так:

language: php

php:
  - 7.1
  - 7.2

env:
  matrix:
    - PREFER_LOWEST="--prefer-lowest --prefer-stable"
    - PREFER_LOWEST=""

before_script:
  - composer update $PREFER_LOWEST

script:
  - composer ci

Можете посмотреть её в работе на примере моей библиотеки mhujer/fio-api-php и матричной сборки Travis CI.

Хотя это решение позволит выловить большинство несовместимостей, помните, что между старшей и младшей версиями существует много комбинаций зависимостей. И они могут быть несовместимы.

Совет № 8: сортируйте пакеты в require и require-dev по имени

Хорошая привычка — держать пакеты в require и require-dev отсортированными по имени. Это поможет пресекать ненужные конфликты слияния при перебазировании ветки. Потому что если вы в двух ветках добавляете пакет в конце списка, то конфликты слияния будут возникать каждый раз.

Вручную это делать нудно, так что лучше сконфигурировать в composer.json:

{
...
    "config": {
        "sort-packages": true
    },
…
}

Когда вы в следующий раз затребуете (require) новый пакет, он будет добавлен в правильное место (не в конец).

Совет № 9: не пытайтесь объединять composer.lock при перебазировании или слиянии

Если вы добавили в composer.json новую зависимость (и composer.lock) и перед слиянием ветки в мастер была добавлена другая зависимость, вам нужно перебазировать ветку. И вы получите в composer.lock конфликт слияния.

Никогда не пытайтесь разрешить его вручную, потому что файл composer.lock содержит хеш зависимостей, определённых в composer.json. Так что, если даже вы разрешите конфликт, получится некорректный lock-файл.

Лучше создавать в корне проекта .gitattributes со следующей строкой, и тогда ваш Git не будет пытаться объединять composer.lock: /composer.lock -merge

Можете решить проблему с помощью кратковременных веток фич (feature branches), как предлагается в Trunk Based Development (это нужно делать в любом случае). Если у вас есть правильно объединённая краткосрочная ветка, риск конфликта слияния в composer.lock минимален. Даже можете создать ветку только для добавления зависимости и сразу объединить её.

Но что делать, если в composer.lock возник конфликт слияния при перебазировании? Разрешите его с помощью версии из мастера, так у вас будут изменения только в composer.json (недавно добавленный пакет). А потом запустите composer update --lock, который захочет обновить файл composer.lock изменениями из composer.json. Теперь можете стейджить обновлённый composer.lock и продолжать перебазирование.

Совет № 10: помните о разнице между require и require-dev

Важно помнить о разнице между блоками require и require-dev.

Пакеты, необходимые для запуска приложения или библиотеки, должны быть определены в require (например, Symfony, Doctrine, Twig, Guzzle…). Если создаёте библиотеку, то будьте осторожны с тем, что кладёте в require. Каждая зависимость в этой секции тоже является зависимостью приложения, использующего библиотеку.

Пакеты, необходимые для разработки приложения или библиотеки, должны быть определены в require-dev (например, PHPUnit, PHP_CodeSniffer, PHPStan).

Совет № 11: обновляйте зависимости безопасно

Полагаю, вы согласны с утверждением, что зависимости нужно регулярно обновлять. И я советую делать обновление зависимостей прозрачно и продуманно, а не по мере какой-то другой работы. Если вы что-то рефакторите и в то же время обновляете какие-то библиотеки, то не сможете сказать, чем сломано приложение, рефакторингом или обновлением.

Используйте команду composer outdated для просмотра, какие зависимости можно обновить. Можно ещё включать --direct (или -D) для вывода только зависимостей, заданных в composer.json. Ещё есть переключатель -m для вывода обновлений только минорных версий.

Для каждой устаревшей зависимости придерживайтесь плана:

Создайте новую ветку.
Обновите в composer.json версию зависимости на самую свежую.
Запустите composer update phpunit/phpunit --with-dependencies (замените phpunit/phpunit названием обновляемой библиотеки).
Проверьте CHANGELOG в репозитории библиотеки на GitHub, чтобы узнать, нет ли всё ломающих изменений. Если есть, обновите приложение.
Локально протестируйте приложение. Если используете Symfony, то можете найти предупреждения о deprecated в панели отладки.
Закоммитьте изменения (composer.json, composer.lock и всё, что нужно для работы новой версии).
Дождитесь окончания CI-сборки.
Объедините и разверните.

Иногда целесообразно обновлять сразу несколько зависимостей, например когда обновляешь Doctrine или Symfony. Тогда лучше перечислить их в команде обновления:

composer update symfony/symfony symfony/monolog-bundle --with-dependencies

Или можете использовать шаблон для обновления всех зависимостей из определённого пространства имён:

composer update symfony/* --with-dependencies

Знаю, всё это выглядит утомительным, но наверняка вы обновляете зависимости по случаю, так что лучше перестраховаться.

Можно лишь в одном облегчить себе работу: разом обновлять все зависимости require-dev (если они не требуют изменений в коде, иначе предлагаю использовать отдельные ветки для упрощения ревизии кода).

Совет № 12: можете определять в composer.json другие типы зависимостей

Помимо определения библиотек в качестве зависимостей, вы также можете определять там и другие вещи.

Например, какие версии PHP поддерживает приложение/библиотека:

"require": {
    "php": "7.1.* || 7.2.*",
},

Или какие расширения необходимы приложению/библиотеке. Это очень полезно, если пытаешься поместить приложение в контейнер или если твой новый коллега впервые настраивает приложение.

"require": {
    "ext-mbstring": "*",
    "ext-pdo_mysql": "*",
},

Используйте * для версий расширений, потому что они могут быть несогласованными.

Совет № 13: проверяйте composer.json в ходе CI-сборки

composer.json и composer.lock должны быть всегда синхронизированы. Поэтому целесообразно автоматически проверять их синхронизированность. Просто добавьте этот механизм в свой скрипт сборки:

composer validate --no-check-all --strict

Совет № 14: используйте Composer-плагин в PHPStorm

Существует composer.json-плагин для PHPStorm. Он добавляет автокомплит и ряд проверок при ручном изменении composer.json.

Если вы используете другую IDE (или только редактор кода), можете настроить проверку его JSON-схемы.

Совет № 15: определяйте в composer.json рабочие версии PHP

Если вы, как и я, любите иногда локально запускать предварительные релизы версий PHP, то рискуете обновить зависимости до версий, не работающих в продакшене. Сейчас я использую PHP 7.2.0, т. е. могу устанавливать библиотеки, которые не будут работать на 7.1. А поскольку продакшен использует 7.1, установка завершится сбоем.

Но переживать не нужно, есть лёгкое решение. Просто определите рабочие версии PHP в разделе config файла composer.json:

"config": {
    "platform": {
        "php": "7.1"
    }
}

Пусть вас не смущает раздел require, который ведёт себя иначе. Ваше приложение может работать на 7.1 или 7.2, но в то же время 7.1 будет определена как платформенная версия, т. е. зависимости всегда будут обновляться до версии, совместимой с 7.1:

"require": {
    "php": "7.1.* || 7.2.*"
},
"config": {
    "platform": {
        "php": "7.1"
    }
},

Совет № 16: используйте приватные пакеты из Gitlab

Рекомендую выбирать vcs в качестве типа репозитория, и Composer должен определить правильный способ извлечения пакетов. Например, если вы добавляете форк с GitHub, он будет использовать свой API для скачивания zip-файла вместо клонирования всего репозитория.

Но с приватной установкой с Gitlab несколько сложнее. Если вы используете vcs в качестве типа репозитория, Composer определит его как Gitlab-установку и попытается скачать пакет через API. Для этого потребуется API-ключ. Я не хотел его настраивать, поэтому сделал так (моя система использует SSH для клонирования).

Сначала определил репозиторий типа git:

"repositories": [
    {
        "type": "git",
        "url": "[email protected]:package-namespace/package-name.git"
    }
]

А затем использовал пакет, как это обычно делается:

"require": {
    "package-namespace/package-name": "1.0.0"
}

Совет № 17: как временно использовать ветку из форка с исправлением бага

Если вы нашли баг в публичной библиотеке и исправили его в своём форке на GitHub, то вам нужно установить библиотеку из своего репозитория, а не из официального (пока исправление не будет объединено и не появится исправленный релиз).

Это легко можно сделать с помощью inline aliasing:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/you/monolog"
        }
    ],
    "require": {
        "symfony/monolog-bundle": "2.0",
        "monolog/monolog": "dev-bugfix as 1.0.x-dev"
    }
}

Можете локально протестировать своё исправление, прежде чем загружать его, используя path в качестве типа репозитория.

Совет № 18: установите prestissimo для ускорения установки пакетов

Composer-плагин hirak/prestissimo ускоряет установку зависимостей посредством параллельного скачивания.

Достаточно установить его один раз глобально, и он будет автоматически работать для всех проектов:

composer global require hirak/prestissimo

Совет № 19: если не уверены, протестируйте свои версионные ограничения

Написание корректных версионных ограничений иногда становится непростой задачей после прочтения документации.

К счастью, есть Packagist Semver Checker, позволяющий проверять, какие версии соответствуют конкретным ограничениям. Вместо простого анализа версионных ограничений данные скачиваются из Packagist для отображения актуальных выпущенных версий.
См. результат для symfony/symfony:^3.1.

Совет № 20: используйте в продакшене авторитарную карту классов (class map)

Сгенерируйте в продакшене авторитарную карту классов. Это ускорит загрузку классов благодаря включению в карту всего необходимого и пропуску любых проверок файловой системы.

Можете делать это в рамках вашей рабочей сборки:

composer dump-autoload --classmap-authoritative

Совет № 21: для тестирования сконфигурируйте autoload-dev

Вам не нужно включать тестовые файлы в рабочую карту классов (из-за размера файла и потребления памяти). Это можно сделать с помощью конфигурирования autoload-dev (аналогично autoload):

"autoload": {
    "psr-4": {
        "Acme\\": "src/"
    }
},
"autoload-dev": {
    "psr-4": {
        "Acme\\": "tests/"
    }
},

советы и приемы использования / Habr

Предлагаю читателям «Хабрахабра» перевод статьи «Mastering Composer – Tips and Tricks» за авторством Bruno Skvorc.

Composer произвел революцию в управлении пакетами в PHP и помог разработчикам по всему миру создавать независимый от фреймворков и разделяемый код. Но все же мало кто выходит за рамки основ его функционала, так что данная статья постарается осветить некоторые полезные приемы его использования.

Глобальная установка (Global)

Несмотря на то, что данная опция доступно описана в документации, Composer может (а в большинстве случаев должен) быть установлен глобально. Глобальная установка означает, что вместо:

php composer.phar somecommand

Вы можете в любом проекте просто ввести:

composer somecommand

Это позволяет очень просто создавать новые проекты (например, с помощью команды create-project) в любом месте вашей файловой системы.

Для установки Composer глобально, следуйте этим инструкциям.

Правильная установка зависимостей

При чтении вводных инструкций или README файлов многие напишут вам что-то вроде:

Just add the following to your composer.json file:
{
    "require": {
        "myproject": "someversion"
    }
}

Но данный подход имеет несколько недостатков. Во-первых, простой копипаст может привести к возникновению ошибок. Во-вторых, для новичка может быть не очевидно, где разместить данный код, если у него и так уже имеется обширный файл composer.json, и это также привести к ошибке. Наконец, некоторые люди будут иметь дело с Composer впервые, а возможно и впервые столкнутся с командной строкой. Поэтому хорошей практикой будет освещение всевозможных случаев, в которых новички могут чувствовать себя неуверенно (есть ли у них графический редактор или они будут использовать командную строку? Если второе, установлен ли в ней текстовый редактор, и если да, то какой? Объясняете ли вы саму процедуру редактирования файла? А что если файла composer.json ещё не существует в проекте? Описываете ли также принцип создания нового файла?).

Наилучший способ добавить новую зависимость в файл composer.json — это воспользоваться командой require:

composer require somepackage/somepackage:someversion

Это добавит все необходимое в файл зависимостей, минуя ручное вмешательство.

Если вам нужно добавить пакеты в раздел require-dev, добавьте в команду опцию —dev:

composer require phpunit/phpunit --dev

Также, команда require поддерживает добавление нескольких пакетов одновременно, для этого просто разделите их пробелом.

Файлы блокировок

Файл composer.lock сохраняет текущий список установленных зависимостей и их версии. Таким образом, на момент, когда версии зависимостей уже будут обновлены, другие люди, которые будут клонировать ваш проект, получат те же самые версии. Это позволяет убедиться в том, что каждый, кто получает ваш проект, имеет “пакетное окружение”, идентичное тому, которое вы использовали при разработке, и помогает избежать ошибок, которые могли бы возникнуть из-за обновления версий.

Файл composer.lock почти всегда должен быть добавлен в систему контроля версий (не всегда).

Также, файл composer.lock содержит хэш файла composer.json, так что, если вы даже просто обновляете данные об авторе проекта, вы получите предупреждение о том, что файл блокировки не соответствует .json файлу. В таком случае, поможет команда composer update —lock, которая обновит только сам файл блокировки, не касаясь ничего другого.

Версионирование

При указании допустимых версий пакетов можно использовать точное соответствие (1.2.3), диапазоны с операторами сравнения (<1.2.3), комбинации этих операторов (>1.2.3 <1.3), “последняя доступная” (1.2.*), символ тильды (~1.2.3) и знак вставки (^1.2.3).

Последние два указания достойны отдельного объяснения:

указание тильды (~1.2.3) будет включать в себя все версии до 1.3 (не включительно), так как в семантическом версионировании это является моментом внедрения новых функциональных возможностей. В данном случае будет получена последняя из стабильных минорных версий. Как гласит документация, при данном указании изменяться может только последняя цифра версии.
указание знака вставки (^1.2.3) буквально означает “опасаться только критических изменений” и будет включать в себя версии вплоть до 2.0. Применительно к semver, изменение мажорной версии является моментом внесения в проект критических изменений, так что версии 1.3, 1.4 и 1.9 подходят, в то время как 2.0 — уже нет.

Кроме случая, когда вы знаете, что вам нужна конкретная версия пакета, я рекомендую всегда использовать формат ~1.2.3 — это самый безопасный выбор.

Локальная и глобальная конфигурация

Значения параметров по-умолчанию не высечены на камне. Подробное описание возможных параметров конфигураций (config) см. по ссылке.

Например, указав:

{
    "config": {
        "optimize-autoloader": true
    }
}

вы заставляете Composer оптимизировать classmap после каждой установки или обновления пакетов (или, другими словами, всякий раз, когда генерируется файл автозагрузки классов). Это немного медленнее, чем создание автозагрузчика по-умолчанию, и замедляется при росте проекта.

Ещё одним полезным параметром может быть cache-files-maxsize. В больших проектах (как eZ Publish или Symfony) кэш может заполниться довольно быстро. Увеличение размера кэша позволить Composer работать быстро дольше.

Обратите внимание, что параметры конфигурации могут быть установлены глобально, и в таком случае будут действовать на все проекты (см. config). Например, чтобы глобально установить параметр размера кэша, нужно либо отредактировать файл ~/.composer/config.json, либо выполнить:

composer config --global cache-files-maxsize "2048MiB"

Профилирование и подробный вывод (verbose)

Если вы добавите параметр —profile к любой команде при использовании Composer в командной строке, то в выводе будет содержаться не только конечный результат, например:

[174.6MB/54.70s] Memory usage: 174.58MB (peak: 513.47MB), time: 54.7s

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

[175.9MB/54.64s] Installing assets for Sensio\Bundle\DistributionBundle into web/bundles/sensiodistribution

Я использую данную опцию для определения “медленных” пакетов и для наблюдения за улучшением или ухудшением производительности на разных версиях PHP.

Подобно предыдущему, параметр —verbose заставит Composer выводить больше информации о каждой выполняемой операции, давая вам понять, что именно происходит в данный момент. Некоторые люди даже устанавливают composer —verbose —profile псевдонимом команды composer по-умолчанию.

Пользовательские источники

Если ваш проект ещё не на Packagist, иногда вам нужно просто установить пакет с GitHub (например, если пакет ещё находится в разработке). Для этого см. наше руководство.

Когда у вас есть своя версия популярного пакета, от которого зависит ваш проект, вы можете использовать пользовательские источники в сочетании с контекстными псевдонимами (inline aliasing), чтобы подставить собственную ветку для публичного пакета, как здесь описал Matthieu Napoli.

Ускорение Composer

Используя отличный метод, описанный Mark Van Eijk, вы можете ускорить выполнение Composer, вызывая его через HHVM.

Ещё один способ — с помощью параметра —prefer-dist, при установке которого Composer будет скачивать стабильные, запакованные версии проекта, вместо клонирования из системы контроля версий (что значительно медленнее). Этот параметр используется по-умолчанию, так что вам не нужно включать его на стабильных проектах. Если вам нужно загрузить проект из исходников, используйте параметр —prefer-source. Подробнее об этом можно узнать в разделе install здесь.

Уменьшение размера проекта Composer

Если вы разработчик «Composer-friendly» проектов, данная часть вас также заинтересует. По этому посту в Reddit, вы можете с помощью файла .gitattributes игнорировать некоторые файлы и папки во время упаковки пакета для режима —prefer-dist.

/docs               export-ignore
/tests              export-ignore
/.gitattributes     export-ignore
/.gitignore         export-ignore
/.travis.yml        export-ignore
/phpunit.xml        export-ignore

Как это работает? Когда вы загружаете проект на GitHub, он автоматически делает доступным ссылку “Download zip”, с помощью которой вы можете скачать архив вашего проекта. Более того, Packagist использует эти автоматически сгенерированные архивы для скачивания зависимостей с опцией —prefer-dist, которые он затем локально разархивирует (намного быстрее клонирования исходных файлов проекта). Если вы при этом добавите в .gitattributes тесты, документацию и прочие файлы, не имеющие отношения к логике работы проекта, указанные архивы не будут их содержать, став гораздо легче.

При этом людям, которые захотят отладить вашу библиотеку или запустить тесты, нужно будет указать параметр —prefer-source.

PhpLeague приняла этот подход и включила его в свой «скелет пакета» (Package skeleton), так что любой основанный на нем проект автоматически будет “dist friendly”.

Show

Если вы вдруг забыли, какую версию PHP или его расширения используете, или вам нужен список всех установленных проектов (с описанием каждого) с их версиями, вы можете использовать команду show с параметрами —platform (-p) и —installed (-i):composer show —installed

$ composer show --installed
 
behat/behat                            v3.0.15            Scenario-oriented BDD framework for PHP 5.3
behat/gherkin                          v4.3.0             Gherkin DSL parser for PHP 5.3
behat/mink                             v1.5.0             Web acceptance testing framework for PHP 5.3
behat/mink-browserkit-driver           v1.1.0             Symfony2 BrowserKit driver for Mink framework
behat/mink-extension                   v2.0.1             Mink extension for Behat
behat/mink-goutte-driver               v1.0.9             Goutte driver for Mink framework
behat/mink-sahi-driver                 v1.1.0             Sahi.JS driver for Mink framework
behat/mink-selenium2-driver            v1.1.1             Selenium2 (WebDriver) driver for Mink framework
behat/sahi-client                      dev-master ce7bfa7 Sahi.js client for PHP 5.3
behat/symfony2-extension               v2.0.0             Symfony2 framework extension for Behat
behat/transliterator                   v1.0.1             String transliterator
components/bootstrap                   3.3.2              The most popular front-end framework for developing responsive, mobile first projects on the web.
components/jquery                      2.1.3              jQuery JavaScript Library
doctrine/annotations                   v1.2.4             Docblock Annotations Parser
doctrine/cache                         v1.4.1             Caching library offering an object-oriented API for many cache backends
doctrine/collections                   v1.3.0             Collections Abstraction library
doctrine/common                        v2.5.0             Common Library for Doctrine projects
doctrine/dbal                          v2.5.1             Database Abstraction Layer
doctrine/doctrine-bundle               v1.4.0             Symfony DoctrineBundle
doctrine/doctrine-cache-bundle         v1.0.1             Symfony2 Bundle for Doctrine Cache
doctrine/inflector                     v1.0.1             Common String Manipulations with regard to casing and singular/plural rules.
doctrine/instantiator                  1.0.4              A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer                         v1.0.1             Base library for a lexer that can be used in Top-Down, Recursive Descent Parsers.
egulias/listeners-debug-command-bundle 1.9.1              Symfony 2 console command to debug listeners
ezsystems/behatbundle                  dev-master bd95e1b Behat bundle for help testing eZ Bundles and projects
ezsystems/comments-bundle              dev-master 8f95bc7 Commenting system for eZ Publish
ezsystems/demobundle                   dev-master c13fb0b Demo bundle for eZ Publish Platform
ezsystems/demobundle-data              v0.1.0             Data for ezsystems/demobundle
ezsystems/ezpublish-kernel             dev-master 3d6e48d eZ Publish API and kernel. This is the heart of eZ Publish 5.
ezsystems/platform-ui-assets-bundle    v0.5.0             External assets dependencies for PlatformUIBundle
ezsystems/platform-ui-bundle           dev-master 4d0442d eZ Platform UI Bundle
ezsystems/privacy-cookie-bundle        v0.1               Privacy cookie banner integration bundle into eZ Publish/eZ Platform
fabpot/goutte                          v1.0.7             A simple PHP Web Scraper
friendsofsymfony/http-cache            1.3.1              Tools to manage cache invalidation
friendsofsymfony/http-cache-bundle     1.2.1              Set path based HTTP cache headers and send invalidation requests to your HTTP cache
guzzle/guzzle                          v3.9.3             PHP HTTP client. This library is deprecated in favor of https://packagist.org/packages/guzzlehttp/guzzle
hautelook/templated-uri-bundle         2.0.0              Symfony2 Bundle that provides a RFC-6570 compatible router and URL Generator.
hautelook/templated-uri-router         2.0.1              Symfony2 RFC-6570 compatible router and URL Generator
imagine/imagine                        0.6.2              Image processing for PHP 5.3
incenteev/composer-parameter-handler   v2.1.0             Composer script handling your ignored parameter file
instaclick/php-webdriver               1.0.17             PHP WebDriver for Selenium 2
jdorn/sql-formatter                    v1.2.17            a PHP SQL highlighting library
knplabs/knp-menu                       v1.1.2             An object oriented menu library
knplabs/knp-menu-bundle                v1.1.2             This bundle provides an integration of the KnpMenu library
kriswallsmith/assetic                  v1.2.1             Asset Management for PHP
kriswallsmith/buzz                     v0.13              Lightweight HTTP client
league/flysystem                       0.5.12             Many filesystems, one API.
liip/imagine-bundle                    1.2.6              This Bundle assists in imagine manipulation using the imagine library
monolog/monolog                        1.13.1             Sends your logs to files, sockets, inboxes, databases and various web services
nelmio/cors-bundle                     1.3.3              Adds CORS (Cross-Origin Resource Sharing) headers support in your Symfony2 application
ocramius/proxy-manager                 0.5.2              A library providing utilities to generate, instantiate and generally operate with Object Proxies
oneup/flysystem-bundle                 v0.4.2             Integrates Flysystem filesystem abstraction library to your Symfony2 project.
pagerfanta/pagerfanta                  v1.0.3             Pagination for PHP 5.3
phpdocumentor/reflection-docblock      2.0.4              
phpspec/prophecy                       v1.4.1             Highly opinionated mocking framework for PHP 5.3+
phpunit/php-code-coverage              2.0.16             Library that provides collection, processing, and rendering functionality for PHP code coverage information.
phpunit/php-file-iterator              1.4.0              FilterIterator implementation that filters files based on a list of suffixes.
phpunit/php-text-template              1.2.0              Simple template engine.
phpunit/php-timer                      1.0.5              Utility class for timing
phpunit/php-token-stream               1.4.1              Wrapper around PHP's tokenizer extension.
phpunit/phpunit                        4.6.4              The PHP Unit Testing framework.
phpunit/phpunit-mock-objects           2.3.1              Mock Object library for PHPUnit
psr/log                                1.0.0              Common interface for logging libraries
qafoo/rmf                              1.0.0              Very simple VC framework which makes it easy to build HTTP applications / REST webservices
sebastian/comparator                   1.1.1              Provides the functionality to compare PHP values for equality
sebastian/diff                         1.3.0              Diff implementation
sebastian/environment                  1.2.2              Provides functionality to handle HHVM/PHP environments
sebastian/exporter                     1.2.0              Provides the functionality to export PHP variables for visualization
sebastian/global-state                 1.0.0              Snapshotting of global state
sebastian/recursion-context            1.0.0              Provides functionality to recursively process PHP variables
sebastian/version                      1.0.5              Library that helps with managing the version number of Git-hosted PHP projects
sensio/distribution-bundle             v3.0.21            Base bundle for Symfony Distributions
sensio/framework-extra-bundle          v3.0.7             This bundle provides a way to configure your controllers with annotations
sensio/generator-bundle                v2.5.3             This bundle generates code for you
sensiolabs/security-checker            v2.0.2             A security checker for your composer.lock
swiftmailer/swiftmailer                v5.4.0             Swiftmailer, free feature-rich PHP mailer
symfony-cmf/routing                    1.3.0              Extends the Symfony2 routing component for dynamic routes and chaining several routers
symfony/assetic-bundle                 v2.6.1             Integrates Assetic into Symfony2
symfony/monolog-bundle                 v2.7.1             Symfony MonologBundle
symfony/swiftmailer-bundle             v2.3.8             Symfony SwiftmailerBundle
symfony/symfony                        v2.6.6             The Symfony PHP framework
tedivm/stash                           v0.12.3            The place to keep your cache.
tedivm/stash-bundle                    v0.4.2             Incorporates the Stash caching library into Symfony.
twig/extensions                        v1.2.0             Common additional features for Twig that do not directly belong in core
twig/twig                              v1.18.1            Twig, the flexible, fast, and secure template language for PHP
white-october/pagerfanta-bundle        v1.0.2             Bundle to use Pagerfanta with Symfony2
whiteoctober/breadcrumbs-bundle        1.0.2              A small breadcrumbs bundle for Symfony2
zendframework/zend-code                2.2.10             provides facilities to generate arbitrary code using an object oriented interface
zendframework/zend-eventmanager        2.2.10             
zendframework/zend-stdlib              2.2.10             
zetacomponents/base                    1.9                The Base package provides the basic infrastructure that all packages rely on. Therefore every component relies on this package.
zetacomponents/feed                    1.4                This component handles parsing and creating RSS1, RSS2 and ATOM feeds, with support for different feed modules (dc, content, creativeCommons, geo, iTunes).
zetacomponents/mail                    1.8.1              The component allows you construct and/or parse Mail messages conforming to  the mail standard. It has support for attachments, multipart messages and HTML  mail. It also interfaces with SMTP to send mail or IMAP, P...
zetacomponents/system-information      1.1                Provides access to common system variables, such as CPU type and speed, and the available amount of memory.

Репетиции (Dry Runs)

Чтобы просто посмотреть, пройдет ли установка новых зависимостей успешно, вы можете использовать параметр —dry-run для команд install и update. Composer в данном случае выведет все потенциальные проблемы без непосредственного выполнения самой команды. Никаких реальных изменений в проекте не произойдет. Этот прием отлично подходит для тестирования сложных зависимостей и настройки изменений перед реальным их внесением.

composer update --dry-run --profile --verbose

Создание проекта

Последнее, но не менее важное, что мы должны упомянуть — это команда create-project.

Команда создания проекта принимает в качестве аргумента имя пакета, который она затем клонирует и выполняет composer install внутри него. Это отлично подходит для инициализации проектов — не нужно больше искать Url нужного пакета на GitHub, клонировать его, самому переходить в папку и выполнять команду install.

Крупные проекты, такие как Symfony и Laravel, уже используют данный подход для инициализации своих «skeleton» приложений, и многие другие также присоединяются.

Например, в Laravel это используется следующим образом:

composer create-project laravel/laravel --prefer-dist --profile --verbose

В команду create-project можно передать еще два параметра: путь, в который нужно установить проект (если не указан, используется имя пакета), и версия (будет использована последняя, если не указать).

Заключение

Надеюсь, данный список советов и приемов использования оказался для вас полезным. Если мы что-то упустили, расскажите нам об этом, и мы обновим статью. И помните, если вы забыли какие-либо команды или опции, просто загляните в шпаргалку. Happy Composing!

PHP Composer для вашего проекта

PHP Composer: личные впечатления

// Ноябрь 14th, 2012 // PHP, Веб-разработка

В этом посте я расскажу о личных впечатлениях от использования такой интересной штуки, как Composer. Если кто не в курсе, это менеджер зависимостей для PHP библиотек, который облегчает установку, обновление и поддержку различных библиотек в вашем проекте.Программисту для комфортной работы нужна инфраструктура (это я вам точно говорю :-). Это и удобное кресло, мощная машина с двумя мониторами, и совеременная IDE, средства работы с базами данных, инструменты отладки. Но кроме того важна инфраструктура разработки самого проекта.

Возьмём к примеру Ruby. Этот язык, блин, ну просто законодатель мод в сфере веб-дева. Там и удобные инструменты скаффолдинга (ну в ZF это тоже есть), и такие штуки, как rake для выполнения задач. Я уж не говорю про миграции, юнит-тесты со всяческими mock-объектами. Когда я кодил на Ruby ощущение было сродни тому, что сидишь в комфортабельном кресле в бизнес-классе в самолете и единственной твоей проблемой является выбор напитка под настроение.

Шучу-шучу. Не всё так радужно в Ruby Есть куча кривых гемов, разработчики иногда выпускают такооое чудо, что мама не горюй. Я уж молчу про низкоуровневое шаманство, когда надо сделать что-то типа распределённой или многопоточной системы. Но речь в посте будет не об этом. А о том, что в Ruby есть такая штук, как RubyGems.

RubyGems это система для управления зависимостями в Ruby проекте. В частности есть такая штука как Bundler, который одним движением устанавливает нужные пакеты или обновляет их. Именно ~~с него наглым образом был списан~~ он послужил вдохновением для Composer.

Что умеет Composer

Итак, краткий обзор фич. Их всего две: управление пакетами и автозагрузка классов. Надо сказать, что без composer обе эти задачи отнимали достаточно много времени. Интернет до сих пор пестрит статьями в стиле «как связать ZF 1.x и Doctrine 2» или «как установить Doctrine 2 ODM и Doctrine 1 ORM». Извращение, скажет вы. Я спеуиально утрировал, но согласитесь, приходится довольно сильно заморачиваться чтобы скрестить некоторые фреймворки или библиотеки. С выходом Composer ситуация поменялась.

Отдельное спасибо надо сказать за человеческую автозагрузку. Ух сколько времени я когда-то потратил на интеграцию Zend_Loader_Autoloader и Doctrine/ClassLoader. Теперь это в прошлом. Садимся в кресло

Пример composer.json

Вот пример файла с описанием зависимостей из одного проекта.

{
"require": {
"doctrine/common": "2.3.0",
"doctrine/migrations": "dev-master",
"doctrine/dbal": "2.3.0",
"doctrine/orm": "2.3.0",
"doctrine/mongodb": "1.0.x-dev",
"doctrine/mongodb-odm": "1.0.x-dev",
"simukti/zf1": "1.12.0",
"zendframework/zendframework": "2.0.3"
},
"autoload": {
"psr-0": {
"ZendExtra": "vendor/netandreus/zend-extra/lib/",
"DoctrineExtra" : "vendor/netandreus/doctrine-extra/lib/",
"MyProject": "vendor/myvendor/myproject/lib/",
"Hydrators": "misc/cache/",
"": "app/default/models/"
}
}

Итак, давайте пройдёмся построчно. В блоке require мы описываем название пакетов в виде vendorName/packageName и минимально необходимые версии для нашего проекта. Потом они будут сами скачиваться и устанавливаться в папку vendor. Как видите Доктрина например раскукожилась сразу в несколько пакетов. Кстати миграции в отдельный пакет выделились совсем недавно, так что следите за новостями проекта. Товарищу simukti выражаю огромную благодарность, за то что он портировал все последние версии ZF 1.x в composer. Когда мне в своё время он понадобился, я начал это делать… да так и не успел в связи с другими задачами. Сейчас же в рамках одного проекта у нас есть возможность использовать компоненты Doctrine 2 ODM + ORM + ZF 1.x + ZF 2.x. Сумасшедший винигрет, но нам он нужен. Т.к. мы потихоньку мигрируем с MySQL (да простит меня Michail Widenius) на MongoDB. Основной костяк — на ZF1, ну а ZF2 — тоже не из праздного любопытсята /* интрига */.

Теперь вторая часть конфига — require. Тут мы задаём классы (вернее их неймспейсы) и места их хранения, т.е. разрешаем пути для соответствующих неймспейсов. Обратите внимание на несколько моментов. Для гидраторов доктрины (если вы не знаете что это, то можете пропустить) указываем пути, т.к. при отсутствующем автозагрузчике доктрины она не может их найти. Последняя строка — местоположение помойки, где могут лежать классы с любыми неймспейсами. Основная особенность Composer в том, что такая помойка (к счастью) может быть только одна. А вот в нашем проекте классы require’ились откуда попало, поэтому пришлось провести так сказать garbage collection и свалить всё в одну кучу. Придётся конечно когда-нибудь и её разобрать, но теперь по крайней месте весь мусор в одном месте. Ну а ZendExtra и DoctrineExtra — этомои расширения, котоыре я частично описывал в своих постах.

Баги Composer

Ну куда же без багов. Самый пожалуй замечатенльный баг fatal: No such remote ‘composer’. Когда вы, уверенные, что у вас всё ок, делаете php composer.phar update, вас ждёт … разочарование. Пробелема в том, что composer не выкачивает исходники (вернее не обновляет их) если указана dev ветка, и исходники старше 6 месяцев. К сожалению в моём composer.json такими оказались пакеты с доктриной. Решение простое, перед тем, как делать update удаляем пакеты с доктриной.

Второй баг был в том, что в репозитарийх некоторых пакетов лежит файл .gitignore, который выкачивается при update/install. А если потом исходники проекта (вместе с этим пакетом) закоммитить, то они не дойдёт. Например в assembla, с которйо я работаю появляется некий пустой файл вместо папки с сорцами. При этом коммит и пуш проходит нормально, а траварищи жалуются, что к ним ничего не прилетает. Решение простое, после Update стираем наифг файлы .gitignore из изходников с пакетами.

Использовать или нет Composer?

Да! Как сказал кто-то, ваша библиотека — отстой, если в её корне не лежит файл composer.json Не ну серьезно, прошли времена php 4, phpclasses, кучи автозагрузчиков в стеке. Давайте перестанем плодить говнокод, будем соблюдать стандарты (ну хотя бы psr-0) и писать так сказать код с человеческим лицом. Я всецело за унификацию и стандартизацию! Enjoy!

Спасибо!

Если вам помогла статья, или вы хотите поддержать мои исследования и блог — вот лучший способ сделать это:

Пакетный менеджер composer.

Всем привет. Сегодня мы поговорим о том, что такое пакетные менеджеры, и рассмотрим один из них — composer.

Для начала разберемся, для чего нужны пакетные менеджеры? Пакетные менеджеры помогают через консоль буквально в паре строк скачать все пакеты, зависимости, какие-то фреймворки, плагины, используемые языком программирования. В нашем случае composer — это пакетный менеджер для языка программирования php.

Чтобы показать вам, как работает composer, давайте скачаем фреймворк yii

Итак, зайдите на сайт http://getcomposer.org/ и нажмите кнопку «Getting Started». Теперь нажмите Installation — *nix, чтобы установить его на Mac или Linux. Откройте терминал и вставьте следующие команды:

1) $ curl -sS https://getcomposer.org/installer | php

2) $ mv composer.phar /usr/local/bin/composer

После того, как вы все сделали, введите команду composer и, если у вас появилась большая надпись «COMPOSER» и некоторая информация, то вы все сделали правильно и composer успешно установился.

Чтобы установить composer на Windows, перейдите по ссылке https://getcomposer.org/doc/00-intro.md#installation-windows и скачайте инсталятор. Если во время установки у вас будут выскакивать ошибки библиотек, то просто зайдите в файл php.ini и отключите те библиотеки, которые не дают установится пакетному менеджеру composer.

После того, как composer установлен, перейдите на рабочий стол и создайте папку с названием «composer». Теперь в консоли перейдите в нее

cd Desktop/composer/

Чтобы инициализировать composer, введите команду

composer init

В чем вообще суть? Суть в том, что когда вы начинаете новый проект, вам не нужно лазить по сайтам и качать все, что для него нужно. Вы просто вводите команду в консоли, и все автоматически скачивается. Еще один плюс в том, что некоторые библиотеки зависят от других библиотек, но вам об этом уже заботиться не нужно, т.к. composer скачает и их. В больших проектах это очень удобно в том плане, что если прийдет, например, новый сотрудник, то вам не нужно объяснять ему, что скачивать и откуда. Вы просто дадите ему json файл, он введет команду в консоли, и все установится.

Продолжим устанавливать наш фреймворк. Как я уже сказал, вводим

composer init

Дальше все можете пропустить, нажимая enter до тех пор, пока не увидите надпись

Search for a package:

Введите тут название нашего фреймворка

Search for a package: yii

Вы увидите перед собой все совпадения, которые нашел composer. Наш нужно yiisoft/yii Слева в квадратных скобках стоит номер. В моем случае это 0, я ввожу его и нажимаю enter. Дальше нам нужно ввести версию. А откуда вообще composer все это качает? Есть такой сайт, где хранится много всякой всячины — http://packagist.org/ Там введите в строке поиска yii и перейдите по первой ссылке, там вы увидите, что версия называется dev-master. Введите это в консоль и нажмите enter.

dev-master

Дальше жмите enter, пока не увидите надпись

Do you confine generation[yes]?

Выше этой надписи вы можете видеть, как выглядит файл composer.json. Это как раз таки тот файл, который вы дадите новому сотруднику.

Итак, нас все устраивает, нажимаем enter.

Теперь, если вы зайдете в нашу папку на рабочем столе composer, то увидите, что там появился наш json файл.

Теперь введите в консоль команду

composer install

После того, как установка будет закончена, в нашей папке на рабочем столе появится новая папка с именем vendor, где хранятся все файлы нашего фреймворка.

Вот так легко работать с пакетным менеджером composer, а главное, что теперь вам не придется скачивать все вручную. Достаточно один раз сделать json файл и затем просто использовать его для скачки и установки нужных вам фреймворком, плагинов, библиотек и прочего.

Создано 17.05.2014 20:25:01
Михаил Русаков

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Компоузер это кто – Объясните, что такое за профессия компоузеры и чем они занимаются?