Composer: Кеш композитора усложняет жизнь разработчикам

У вас есть какие-нибудь подробности по этому поводу? Какая часть кеша выходит из строя и как? Насколько я знаю, у меня никогда не было проблем с кешем, и я тоже работаю над win7.

Прошу прощения за очень общую проблему, я знаю, не очень полезную. Просто мы еще не увидели четкой закономерности. Часто случается, что в dev-master явно есть новые коммиты, а старые просто берутся из кеша. Композитор говорит: установка из кеша, но мы знаем, что это не то, что нам нужно. Единственный способ получить новую информацию - удалить кеш. Было бы намного проще иметь метод composer clear-cache . Может, есть что-то, что мы делаем неправильно ... Хотя я не знаю что.

О, и у нас была такая же проблема с CentOS, кстати.

ИМО, команда очистки кеша просто сдалась бы и признала неудачу. Я лучше исправлю основную причину. Кэш должен быть прозрачным, иначе он станет болезненным источником неопределенности. Вот почему я удивлен, что у вас есть проблемы, потому что я делаю все, что в моих силах, чтобы сделать кеши зависимыми от точных версий вещей, чтобы в случае каких-либо изменений он стал недействительным.

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

• Соберите вывод и вставьте его сюда (особенно интересуют версии пакета от / до).
• запустите и скопируйте вывод этого в cmd.exe: dir %LOCALAPPDATA%\Composer\files\<package name> чтобы увидеть, какие версии / файлы точно находятся в кеше (если на CentOS: ls -l ~/.composer/cache/files/<package name> ).

хорошо, сделаю это.

Я работаю с Маркусом, и эта проблема у меня возникала более одного раза (в Windows 8 и CentOS), например, когда мне нужно было добавить некоторые недостающие файлы в тег git. Я сделал следующее:

• добавлены файлы в локальное репо
• воссоздал тег (принудительная перезапись)
• отправил тег в github
• перестроил пакеты composer / satis
• запустил php composer.phar update в моем проекте

Даже после ручного удаления всех зависимостей перед запуском php composer.phar update композитор устанавливает тег из кеша вместо получения обновленного тега с добавленными файлами. После очистки кеша вручную композитор устанавливает обновленный тег.

Теги @aimfeld Git не подлежат изменению. Когда вы перезаписываете тег, каждый парень, который уже получил старый тег, должен удалить его в своем клоне и получить его снова, иначе они все равно будут использовать старый тег.
Таким образом, это может быть проблема с кешем (который уже содержит старый тег), но даже без кеша он может сломаться, если вы уже загрузили старый тег в папку поставщика (с установкой из источника), поскольку вы установите старый тег позже при использовании тега в качестве ссылки git.

@stof Это верно в большинстве случаев, но здесь мы говорим о

@markushausammann даже для частных репозиториев. Если вы удалите тег git и создадите его заново, любой парень, который уже клонировал репо со старым тегом, должен будет удалить тег и снова выполнить выборку. Если у вас есть какие-то исправления, вы должны сделать _новую_ версию с исправлением ошибок, а не стирать предыдущую.

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

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

@markushausammann @aimfeld действительно проблема с изменением тегов. Это действительно плохая практика. Если 1.0.0 не работает, вы можете отправить исправления и выпуск 1.0.0.1 или 1.0.0p1, которые оба принимаются композитором как второстепенные выпуски исправлений / исправлений.

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

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

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

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

Ты такой конструктивный :)

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

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

У меня была аналогичная проблема при перемещении пакета из упаковщика на сервер Satis. Тег остался прежним, так как репо не изменилось, контрольная сумма md5 не прошла (я не уверен, что в нее входит). Может ли контрольная сумма одного и того же пакета у packagist / satis отличаться или мне что-то не хватает?

Может быть, нужно очистить кеш для pacakge, если контрольная сумма не сработает?

@tomaszdurka Я думаю, что
Подсчитывается ли контрольная сумма файлов до или после упаковки?
Возможно, эта ошибка эмуляции .gitignore также влияет на переупаковку.

Это zip одного и того же репо, того же ref / tag:

• MD5 (/tmp/satis.zip) = 0b719b5685591286446476dbc6789698
• MD5 (/tmp/packagist.zip) = 82aa4716f2523a9039507d01bbc709a2

На самом деле:
Кажется, что упаковщик упаковывает пакет в каталог ( <project-name>-<version> ), а satis - нет. Вероятно, это больше проблема для проекта https://github.com/composer/satis .

Здесь мы сталкиваемся с обеими проблемами

• другой ШАСУМ, на 2 сатисах (которые используют одну и ту же конфигурацию)
• кеш раздражает нас при обновлении или установке через композитор.

@Seldaek Вы получали уведомления об этом?

Привет,

У меня были ошибки контрольной суммы при использовании Satis; Больше не делаю, так как отключил кеш с обеих сторон:

"config:{
    "cache-files-ttl": 0
}

Через несколько недель я заметил, что кешированные ZIP-файлы имеют контрольные суммы, отличные от контрольных сумм исходных файлов на satis.

Затем композитор говорит что-то вроде:

 - Installing easybook/geshi (1.0.8.11)
    Loading from cache

  [UnexpectedValueException]                                                                                                                                                  
  The checksum verification of the file failed (downloaded from http://satis.cargomedia.ch/dist/dist/easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip)  

Кешированный файл действительно отличается от того, что находится на satis:

$ md5sum ~/.composer/cache/files/easybook/geshi/1.0.8.11-1.0.8.11.zip 
f26396c9ca9f2e89e3c99edfa4a5401e  /root/.composer/cache/files/easybook/geshi/1.0.8.11-1.0.8.11.zip
$ curl -s http://satis.cargomedia.ch/dist/dist/easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip | md5sum
f99a691ad94190be33f6321cb769c8e7  -

Если я распаковываю оба ZIP-файла, они идентичны ( diff -r ), но сами ZIP-файлы разные:

$ diff easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip 1.0.8.11-1.0.8.11.zip 
Binary files easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip and 1.0.8.11-1.0.8.11.zip differ

С разницей, похожей на другую кодировку (?):

$ diff -a easybook-geshi-2582e8134c8af41d7f367e421ee0b8b111e89f36-zip-f3a77f.zip 1.0.8.11-1.0.8.11.zip 
1c1
composer.jsonnuW+A??{
---
composer.jsonnuW+A??{
24c24
< }PKBC??n??    README.mdnuW+A??# GeSHi - Generic Syntax Highlighter #
---
> }PKy??B??n??  README.mdnuW+A??# GeSHi - Generic Syntax Highlighter #
[.....]

Есть идеи, что может быть причиной или как продолжить отладку?

Это скорее похоже на проблему Satis, связанную с тем, что алгоритм ZIP не является детерминированным. Composer ничего не меняет в ZIP-файле, загруженном с сервера Satis; проблема возникает только если:

• Composer загружает пакет из Satis, помещает его в кеш и записывает свою контрольную сумму в composer.lock
• Сервер Satis снова генерирует ZIP-файл для того же пакета, хотя сам пакет и его номер версии не изменились. Однако этот новый ZIP-файл отличается от исходного - на мой взгляд, это и есть настоящая ошибка.
• Кэш Composer очищается или Composer запускается на другом компьютере, где пакет еще не был загружен
• composer install загружает новый ZIP-файл с сервера Satis

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

В принципе, эта проблема не ограничивается только Satis; любой менеджер пакетов, который «обновляет» архивы пакетов, хотя их номер версии не изменился, вызовет ту же проблему.

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

find . -type f -exec md5sum {} + | awk '{print $1}' | md5sum

(вдохновленный этим ответом на StackOverflow)

@killerwolf Это раздражает, но я думаю понятно, что с двумя экземплярами Satis работать нельзя. Оба будут повторно упаковать исходные пакеты и сгенерировать ZIP-файлы с разными контрольными суммами, хотя раздутое содержимое одинаково.

Я заглянул в Composer\Satis\Command\BuildCommand::dumpDownloads() , и мне кажется, что Satis не будет перезаписывать существующие архивы пакетов при повторной сборке сервера, поскольку мы используем:

$archiveManager->setOverwriteFiles(false);

Таким образом, проблема может возникнуть только в том случае, если вы вручную удалите архивы пакетов с сервера Satis, а затем заново создадите его? Может ли кто-нибудь подтвердить или опровергнуть эту теорию?

@Seldaek, что насчет моего предложения? Было бы неплохо добавить контрольную сумму _inflated_ архивов, возможно, с помощью новой записи shasum-inflated в composer.lock ? Затем мы могли бы использовать его как запасной вариант в случае, если контрольная сумма самого архива не совпадает.

Кажется, проблема для нас была в более старом composer.lock который использовал имена файлов из satis, например ruflin-elastica-v0.19.8.0-v0.19.8.0-93e4c9.zip вместо того, что кажется теперь ruflin-elastica-34a7e62a257febd5295efeacfa0209712e0ceb65-zip-f92c51.zip .
Эти два файла содержат одну и ту же версию библиотеки и, таким образом, обрабатываются кешем композитора как один и тот же файл. Так как на Satis это были разные ZIP-файлы, то и шасумы различались.
Теперь satis правильно использует только последнее имя файла, поэтому повторное создание composer.lock должно решить эти проблемы.

Так что, похоже, на самом деле есть две проблемы:

• Если в локальном кэше есть zip-архив, и он был восстановлен, эти архивы могут больше не совпадать.
• Если satis перестроен, то хеш в composer.lock может быть устаревшим и не совпадать.

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

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

Есть идея получше?

Мне только что пришлось перестроить все наши кэши пакетов и заново создать composer.lock во всех проектах. Причина, по моему мнению, заключалась в изменении Satis или Composer (теперь имена файлов содержат шасумы вместо номеров версий).

Чтобы предотвратить это, вероятно, самым безопасным было бы вычислить шасум на основе содержимого ZIP.
Недостатками являются более низкая производительность записи и необходимость воссоздавать много composer.lock s - так что не уверен ..

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

Как насчет расширения архивов пакетов в памяти для расчета завышенной контрольной суммы, которую мы сохраним в composer.lock ?

Это не будет работать в системах без расширения zip, и даже на тех
это все еще намного медленнее, чем просто хеширование всего архива.

Правильно ... Что касается производительности, в "нормальном" случае composer install не пострадает, так как мы будем вычислять только завышенную контрольную сумму в composer update , чтобы сохранить это в composer.lock . Мы бы вычислили его только для composer install если дефлированная контрольная сумма не совпадает - в качестве запасного варианта. И в этом случае мы могли бы обновить дефлированную контрольную сумму в composer.lock , чтобы она соответствовала в следующий раз. (Я просто надеюсь, что это не приведет к возникновению новых проблем с безопасностью - нам нужно быть осторожными ...)

Поскольку это всего лишь удобная функция, мы могли бы сделать ее необязательной, я думаю?

Мой текущий обходной путь - export COMPOSER_CACHE_DIR=/dev/null чтобы избежать прерывания процесса автоматической установки, но все файлы доступны в локальной сети, поэтому дополнительная повторная загрузка не является проблемой.

Я столкнулся с проблемой недетерминированности алгоритма ZIP: я использую сервер Linux в компании, которая создает репозиторий с помощью Satis. На своей домашней рабочей станции я хочу предоставить второй репозиторий Satis с теми же пакетами, которые предпочтительно использовать в моей установке Composer, потому что к нему быстрее получить доступ локально, чем через Интернет.

Проблема в том, что моя локальная рабочая станция работает под управлением Windows 7, а Zip-файлы, созданные с помощью установки Satis, отличаются от тех, что созданы на сервере Linux. Это приводит к проблемам с контрольной суммой всякий раз, когда Zip с одного сервера находится в кеше, а Composer ожидает контрольную сумму от другого.

Я думаю, что это реальная проблема, потому что предоставление одних и тех же пакетов из разных источников - это основная концепция, обеспечивающая избыточные источники данных. Есть два способа справиться с этим:

1. Убедитесь, что хэши пакетов зависят не от окончательного Zip-архива, а от детерминированного представления данных в несжатом виде.
2. Хранить пакеты в кеше не только по имени, но и по серверу-источнику. Это может быть временным решением проблемы несогласованности межсерверного алгоритма ZIP.

Сегодня я столкнулся с несколько другим вариантом проблемы, заключающейся в том, что Composer вычисляет хеш для сжатой версии, а не для исходных данных. На этот раз очистки кеша было недостаточно, потому что в соответствующем проекте был зарегистрирован файл composer.lock и поэтому Composer настоял на получении архива с хешем, который больше не был доступен, потому что сжатая версия пакета изменилась. тем временем пока исходные данные остались без изменений. Это было проверено путем сравнения результатов в каталогах vendor двух установок после принудительной установки путем удаления файла composer.lock . Изменилась только запись shasum двух пакетов, все остальное осталось прежним.

Добавление кеша ttl 0 insta-сработало для меня, спасибо.

+1

Изменить после комментария @markushausammann ниже:
Это вызывает у меня проблему не реже одного раза в день. Я не хочу устанавливать cache-ttl в каждом из моих проектов composer.json.

Моя оценка выполняется каждые 5 минут с полной сборкой и после каждого нажатия на определенные проекты.

: +1:

Я действительно не уверен, что вы, ребята, забираете. В этом выпуске было сказано так много всего, что это может быть что угодно, от «да, это тоже усложняет мою жизнь» до «cache ttl 0 works». Если вы поставили +1 или подняли палец вверх, объясните, что вы поддерживаете.

Ну да, это PITA, и "cache-files-ttl": 0 пока "исправляет" его, но это совсем не оптимально. Было бы лучше заменить предыдущий кеш, когда контрольная сумма отличается, композитор в любом случае не может сказать, какой из них хороший: кеш или удаленный архив, поэтому давайте предположим, что новый в порядке, и использовать его, чтобы избежать поломки по развертыванию. Это кеш, а не проверка целостности репозитория, он должен быть прозрачным, и никому не нужно о нем заботиться.

@ peikk0 : +1 при замене кешированного файла на разницу контрольных сумм.

На сегодняшний день это будет самое простое решение текущих проблем.
Установка "cache-files-ttl": 0 не является решением, это означает просто полностью отказаться от идеи кеширования.

Я исправил то, что сейчас поправимо, т.е. "поврежденные" кеши, которые не соответствуют sha-1, больше не будут использоваться, и вместо этого будет произведена повторная загрузка. Остальная часть номера перенесена в № 2540.

Кеш по-прежнему не работает при использовании @dev версии пакетов, размещенных на Github:

Composer version 1.2.1 2016-09-12 11:27:19

$ composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing level-2/transphporm (dev-master 2110304)
    Cloning 2110304c512958797508ea08e0d78c4336494b41 from cache

Writing lock file
Generating autoload files
master

$ git log origin
commit 0ada294c2ecd1698782985a23f3c90c142fab7b4 (refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/remotes/composer/master)
Author: Tom Butler <[email protected]>
Date:   Tue Sep 13 15:51:36 2016 +0100

    #124 - fixed bug with empty value

commit 2110304c512958797508ea08e0d78c4336494b41 (HEAD -> refs/heads/master)
Author: Richard <[email protected]>
Date:   Fri Aug 12 08:17:02 2016 -0400

    Removed unused class properties

Обратите внимание, как Composer вытащил старую версию 2110304 от 12 августа из кеша вместо того, чтобы получить версию 0ada294c из Github.

@cxj, пожалуйста, сообщите о новой проблеме, вместо того, чтобы