Типичные ошибки Composer и способы их устранения

1. Устранение неисправностей
2. Общие сведения
3. Пакет не найден
4. Пакет не обновляется до ожидаемой версии
5. Зависимости от корневого пакета
6. Проблемы таймаута соединения, ошибка curl
7. Пакет не найден в Jenkins-сборке
8. У меня есть зависимость, которая содержит определение "repositories" в composer.json, но оно, похоже, игнорируется
9. Я привязал зависимость к определённому коммиту, но получаю неожиданные результаты
10. Необходимо переопределить версию пакета
11. Определение того, откуда взялось значение конфигурации
12. Ошибки ограничения памяти
13. Влияние Xdebug на Composer
14. "Система не может найти указанный путь" (Windows)
15. Ограничение скорости работы API и токены OAuth
16. proc_open(): fork failed errors
17. proc_open(): failed to open stream errors (Windows)
18. Режим деградации
19. Операция завершается по таймеру (проблемы с IPv6)
    
    1. Решение проблемы в Linux
    2. Решение проблемы в Windows
    3. Решение проблемы в Mac OS X
20. Composer зависает при использовании SSH ControlMaster
21. Zip-архивы распаковываются некорректно
22. Отключение оптимизатора пула

Устранение неисправностей

Ниже приведен список распространенных подводных камней при использовании Composer и способы их избежать.

Общие сведения

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

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

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

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

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

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

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

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

Проблемы таймаута соединения, ошибка curl

Если вы видите что-то вроде:

Failed to download * curl error 28 while downloading * Operation timed out after 300000 milliseconds

Это означает, что ваша сеть, вероятно, настолько медленная, что для выполнения запроса потребовалось более 300 секунд. Это минимальный таймаут, который будет использовать Composer, но его можно увеличить, увеличив значение default_socket_timeout в вашем php.ini.

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

1. Посмотрите пункт "Пакет не найден" выше.
2. При git-clone / checkout в Jenkins ветка остается в статусе "detached HEAD". В результате Composer может не определить версию текущей проверенной ветки и не разрешить зависимости от корневого пакета. Чтобы решить эту проблему, вы можете использовать "Additional Behaviours" -> "Check out to specific local branch" в настройках Git для вашего Jenkins-job, где ваша "локальная ветка" должна быть той же веткой, которую вы проверяете. В этом случае проверка больше не будет находиться в отделённом состоянии, а зависимость от корневого пакета должна быть реализована.

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

Свойство конфигурации repositories определено как root-only. Оно не наследуется. Подробнее о причинах этого вы можете прочитать в статье "Почему Composer не может загружать репозитории рекурсивно?". Самым простым решением этой проблемы является перемещение или дублирование определения 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 <...>

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

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

Влияние Xdebug на Composer

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

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

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

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

Ограничение скорости работы API и токены OAuth

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

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

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

proc_open(): fork failed errors

Если Composer показывает, что форк proc_open() не выполнен для некоторых команд:

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

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

free -m

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

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

/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

Создать постоянный файл swap можно, следуя этому руководству.

proc_open(): failed to open stream errors (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 Service. Для получения дополнительной информации смотрите этот материал.

Режим деградации

Из-за периодически возникающих проблем в 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.

В качестве обходного пути откройте SSH-соединение с хостом Git перед запуском 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

Теперь проверьте, не изменился ли результат. Процесс разрешения зависимостей займет значительно больше времени и потребует больше памяти.

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

Перевод с английского официальной документации Composer:
https://getcomposer.org/doc/articles/troubleshooting.md

Заберите ссылку на статью к себе, чтобы потом легко её найти!
Раз уж досюда дочитали, то может может есть желание рассказать об этом месте своим друзьям, знакомым и просто мимо проходящим?
Не надо себя сдерживать! ;)