Устранение неполадок

В этом списке перечислены распространённые ошибки при использовании Composer и способы их предотвращения.

Общие

При возникновении проблем с Composer, убедитесь, что вы используете самую последнюю версию. Подробности см. в self-update.
Перед обращением к кому-либо, выполните composer diagnose, чтобы проверить наличие распространённых проблем. Если всё в порядке, переходите к следующим шагам.
Убедитесь, что у вас нет проблем с настройкой, выполнив проверки установщика с помощью curl -sS https://getcomposer.org/installer | php -- --check.
Попробуйте очистить кэш Composer, выполнив composer clear-cache.
Убедитесь, что вы устанавливаете поставщиков напрямую из composer.json с помощью rm -rf vendor && composer update -v, чтобы исключить возможные конфликты с существующими установками поставщиков или composer.lock записями.

Пакет не найден

Тщательно проверьте, что в вашем composer.json или ветках и тегах репозитория нет опечаток.
Убедитесь, что вы установили правильную минимальную стабильность. Для начала или для уверенности в отсутствии проблем, установите minimum-stability в «dev».
Пакеты, не происходящие из Packagist, должны всегда определяться в корневом пакете (пакете, зависящем от всех поставщиков).
Используйте одно и то же имя поставщика и пакета во всех ветках и тегах вашего репозитория, особенно при работе с сторонними разветвлениями и использовании replace.
Если вы обновляете недавно опубликованную версию пакета, имейте в виду, что Packagist может иметь задержку до 1 минуты, прежде чем новые пакеты станут доступны Composer.
Если вы обновляете отдельный пакет, он может зависеть от более новых версий. В этом случае добавьте параметр --with-dependencies или добавьте все зависимости, которые требуют обновления, в команду.

Пакет не обновляется до ожидаемой версии

Попробуйте выполнить php composer.phar why-not [package-name] [expected-version].

Зависимости от корневого пакета

Когда ваш корневой пакет зависит от пакета, который в конечном итоге зависит (прямо или косвенно) обратно от самого корневого пакета, могут возникнуть проблемы в двух случаях:

Во время разработки, если вы находитесь на ветке, такой как dev-main и в ветке нет branch-alias, а зависимость от корневого пакета требует версии ^2.0, например, то версия dev-main её не удовлетворит. Лучшее решение - убедиться, что вы сначала определили псевдоним ветки.
В запусках CI (Continuous Integration), проблема может заключаться в том, что Composer не может правильно определить версию корневого пакета. Если это git clone, то это, как правило, в порядке, и Composer определит версию текущей ветки, но некоторые CI делают поверхностные клоны, поэтому этот процесс может завершиться неудачно при тестировании pull-запросов и ветвей функций. В этих случаях псевдоним ветки может не распознаваться. Лучшее решение - определить версию, на которой вы находитесь, через переменную среды с именем COMPOSER_ROOT_VERSION. Вы устанавливаете её в dev-main например, чтобы определить версию корневого пакета как dev-main. Используйте, например, COMPOSER_ROOT_VERSION=dev-main composer install чтобы экспортировать переменную только для вызова composer, или вы можете определить её глобально в переменных среды CI.

Пакет не найден в Jenkins-построении

Проверьте пункт "Пакет не найден" выше.
git-клон/выборка в Jenkins оставляет ветку в состоянии "detached HEAD". В результате Composer может не определить версию текущей выбранной ветки и не сможет разрешить зависимость от корневого пакета. Чтобы решить эту проблему, вы можете использовать «Дополнительные действия» -> «Выборка в определённую локальную ветку» в настройках Git для вашей задачи Jenkins, где ваша «локальная ветка» должна быть такой же, как ветка, которую вы выбираете. При этом выборка больше не будет находиться в состоянии detached и зависимость от корневого пакета должна быть удовлетворена.

У меня есть зависимость, содержащая определение «repositories» в composer.json, но оно, кажется, игнорируется.

Свойство конфигурации repositories определено как root-only. Оно не наследуется. Вы можете узнать больше о причинах этого в статье "why can't Composer load repositories recursively?". Самый простой способ обойти это ограничение - перенести или дублировать определение repositories в ваш корневой composer.json.

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

Хотя Composer поддерживает блокирование зависимостей до определённого коммита с помощью синтаксиса #commit-ref, существуют определённые оговорки, которые следует учитывать. Наиболее важная из них документирована, но часто упускается из виду:

Примечание: Хотя это бывает удобно, это не должно быть способом использования пакетов в долгосрочной перспективе, поскольку это связано с техническим ограничением. Метаданные composer.json всё равно будут считываться из имени ветки, которое вы указываете перед хешем. Из-за этого в некоторых случаях это не будет практичным решением, и вы всегда должны стараться переключиться на помеченные релизы, как только сможете.

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

Нужно переопределить версию пакета

Предположим, ваш проект зависит от пакета A, который, в свою очередь, зависит от определённой версии пакета B (скажем, 0.1). Но вам нужна другая версия этого пакета B (скажем, 0.11).

Вы можете исправить это, создав псевдоним версии 0.11 на 0.1:

composer.json:

{
    "require": {
        "A": "0.2",
        "B": "0.11 as 0.1"
    }
}

См. псевдонимы для получения дополнительной информации.

Выяснение источника значения конфигурации

Используйте php composer.phar config --list --source для просмотра источника каждого значения конфигурации.

Ошибки ограничения памяти

Прежде всего, убедитесь, что вы используете Composer 2, а если возможно, 2.2.0 или выше.

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

Иногда Composer может завершиться неудачно с сообщением:

PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted <...>

В этом случае необходимо увеличить предел PHP memory_limit.

Примечание: Composer внутренне увеличивает memory_limit до 1.5G.

Чтобы получить текущее значение memory_limit, выполните:

php -r "echo ini_get('memory_limit').PHP_EOL;"

Попробуйте увеличить предел в вашем файле php.ini (например, /etc/php5/cli/php.ini для систем на базе Debian):

; Use -1 for unlimited or define an explicit value like 2G
memory_limit = -1

Composer также учитывает ограничение памяти, определённое переменной среды COMPOSER_MEMORY_LIMIT.

COMPOSER_MEMORY_LIMIT=-1 composer.phar <...>

Или вы можете увеличить предел с помощью аргумента командной строки:

php -d memory_limit=-1 composer.phar <...>

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

Влияние Xdebug на Composer

Для повышения производительности при включённом расширении Xdebug Composer автоматически перезапускает PHP без него. Вы можете переопределить это поведение, используя переменную среды: COMPOSER_ALLOW_XDEBUG=1.

Composer всегда будет выводить предупреждение, если используется Xdebug, но вы можете переопределить это с помощью переменной среды: COMPOSER_DISABLE_XDEBUG_WARN=1. Если вы видите это предупреждение неожиданно, процесс перезапуска не удался: сообщите об этой ошибке.

"Система не может найти указанный путь" (Windows)

Откройте regedit.
Найдите ключ AutoRun в HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor, HKEY_CURRENT_USER\Software\Microsoft\Command Processor или HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Command Processor.
Проверьте, содержит ли он пути к несуществующим файлам. Если это так, удалите их.

Предел скорости API и токены OAuth

Из-за ограничений скорости API GitHub может произойти запрос Composer на авторизацию, попросив ваш логин и пароль, чтобы он мог продолжить работу.

Если вы не хотите предоставлять Composer свои учётные данные GitHub, вы можете вручную создать токен, используя процедуру, описанную здесь.

Теперь Composer должен устанавливать/обновлять без запроса на авторизацию.

Ошибки proc_open(): fork failed

Если Composer показывает ошибку proc_open() fork failed для некоторых команд:

PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar

Это может происходить из-за того, что VPS закончилась памятью, и не включён кэш-обмен.

free -m

total used free shared buffers cached
Mem: 2048 357 1690 0 0 237
-/+ buffers/cache: 119 1928
Swap: 0 0 0

Чтобы включить кэш-обмен, вы можете использовать, например:

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/bin/chmod 0600 /var/swap.1
/sbin/swapon /var/swap.1

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

Ошибки proc_open(): failed to open stream (Windows)

Если Composer показывает ошибки proc_open(NUL) на Windows:

proc_open(NUL): failed to open stream: No such file or directory

Это может происходить, потому что вы работаете в каталоге OneDrive и используете версию PHP, которая не поддерживает семантику файловой системы этого сервиса. Проблема была решена в PHP 7.2.23 и 7.3.10.

В качестве альтернативы, это может быть связано с тем, что служба Windows Null не включена. Для получения дополнительной информации см. эту ошибку.

Режим пониженной производительности

Из-за некоторых периодических проблем на Travis и других системах мы ввели режим пониженной производительности сети, который помогает Composer успешно завершить работу, но отключает некоторые оптимизации. Он включается автоматически при обнаружении проблемы. Если вы видите эту проблему периодически, то, вероятно, беспокоиться не о чем (медленная или перегруженная сеть также может вызвать эти временные задержки), но если она появляется многократно, вы можете изучить варианты ниже, чтобы определить и устранить её.

Если вас перенаправили на эту страницу, проверьте несколько вещей:

Если вы используете антивирус ESET, перейдите в "Дополнительные настройки" и отключите "Сканер HTTP" в разделе "Защита веб-доступа"
Если вы используете IPv6, попробуйте отключить его. Если это решит проблемы, свяжитесь с вашим интернет-провайдером или хостинг-провайдером сервера. Проблема не в Packagist, а в правилах маршрутизации между вами и Packagist (то есть, в интернете в целом). Лучший способ исправить это — привлечь внимание сетевых инженеров, у которых есть полномочия на исправление. Обратите внимание на следующий раздел для решений по работе с IPv6.
Если ничто из вышеперечисленного не помогло, пожалуйста, сообщите об ошибке.

Время ожидания истекло (проблемы с IPv6)

Вы можете столкнуться с ошибками, если IPv6 не настроен правильно. Типичная ошибка:

The "https://getcomposer.org/version" file could not be downloaded: failed to
open stream: Operation timed out

Мы рекомендуем исправить вашу настройку IPv6. Если это невозможно, вы можете попробовать следующие обходные пути:

Решение для Linux:

В Linux, кажется, выполнение этой команды помогает придать трафику IPv4 более высокий приоритет, чем IPv6, что является лучшей альтернативой полному отключению IPv6:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

Решение для Windows:

К сожалению, в Windows единственный способ — полностью отключить IPv6 (либо в Windows, либо в вашем домашнем роутере).

Решение для Mac OS X:

Получение имени сетевого устройства:

networksetup -listallnetworkservices

Отключение IPv6 на этом устройстве (в данном случае "Wi-Fi"):

networksetup -setv6off Wi-Fi

Запуск Composer ...

Вы можете снова включить IPv6 с помощью:

networksetup -setv6automatic Wi-Fi

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

Composer зависает с SSH ControlMaster

При попытке установить пакеты из Git-репозитория и использовании параметра ControlMaster для подключения SSH, Composer может зависнуть и вы увидите процесс sh в состоянии defunct в списке процессов.

Причина в ошибке SSH: https://bugzilla.mindrot.org/show_bug.cgi?id=1988

В качестве обходного решения, подключитесь к вашему Git-хосту через SSH до запуска Composer:

ssh -t git@mygitserver.tld
php composer.phar update

См. также https://github.com/composer/composer/issues/4180 для получения дополнительной информации.

Архивы zip не распаковываются корректно.

Composer может распаковывать zip-архивы, используя либо предоставляемую системой утилиту unzip, либо 7z (7-Zip), или встроенный в PHP класс ZipArchive. На операционных системах, где ZIP-архивы могут содержать разрешения и символьные ссылки, мы рекомендуем установить unzip или 7z, поскольку эти функции не поддерживаются ZipArchive.

Отключение оптимизатора пула

В Composer класс Pool содержит все пакеты, которые релевантны для процесса разрешения зависимостей. Именно он используется для генерации всех правил, которые затем передаются решателю зависимостей. Чтобы улучшить производительность, Composer пытается оптимизировать этот Pool путём удаления ненужной информации о пакетах на ранних этапах.

При нормальной работе вы не должны замечать каких-либо проблем, но если вы столкнётесь с неожиданным результатом, например, с неразрешимым набором зависимостей или конфликтами, где вы считаете, что Composer ошибается, вы можете отключить оптимизатор, используя переменную окружения COMPOSER_POOL_OPTIMIZER и запустив обновление повторно следующим образом:

COMPOSER_POOL_OPTIMIZER=0 php composer.phar update

Теперь проверьте, является ли результат таким же. Это займёт значительно больше времени и потребует больше памяти для выполнения процесса разрешения зависимостей.

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