Это как-то стандартное поведение из-за документации композитора --no-cache "Отключает использование каталога кэша. То же, что и установка переменной env переменной COMPOSER_CACHE_DIR в / dev / null", prestissimo полагается на каталог кэша композитора, даже когда он выполняетсябез кеша, и я отлаживал его через исходный код GitHub композитора, и он не удался в prestissimo классе в корневом методе CopyRequest.php createDir, строка 103
private function createDir($fileName)
{
$targetdir = dirname($fileName);
if (!file_exists($targetdir)) {
if (!mkdir($targetdir, 0775, true)) {
throw new FetchException(
'The file could not be written to ' . $fileName
);
}
}
}
target dir в случае предоставления --no-параметр кэша установлен в '/ dev / null / что-то / long / path', возможно, параметр composer --debug даст больше информации о трассировке, возможно, не
Вывод:
Даже когда я вернулся к старому composer.lock, я получил ту же ошибку в Yii 1, получая фреймворк из кеша, возможно, из кеша получен диапазон младших версий, поэтому я хотел посмотреть, получит ли очистка кеша правильныйСостояние из истории как возвращение даже с кешем в прошлое, похоже, не помогло - можно сказать, что не кешированная версия должна совпадать сПодойдет, но, чтобы быть полностью уверенным (не всегда каждый разработчик увеличивает версию с каждым коммитом - более того, при восстановлении артефакта Bamboo CI де-факто очищается кеш-память), более того, параллельная загрузка кеша с prestissimo бесполезна.
чтобы удалить или обойти кэш композитора, мне пришлось вручную удалить его с помощью командной строки linux, удалив глобальный каталог кэша композитора.
Ошибка упоминается в библиотеке prestissimo https://github.com/hirak/prestissimo/issues/199