<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ну, как устроена реальная жизнь:<div class=""><br class=""></div><div class="">День 1: программисты хотят 10 пакетов, вместе с зависимостями это, допустим, 182 штуки. Во время «вместе с зависимостями» было сколько-то обращений к оглавлению за метаданными. Допустим, они все GET и настолько простые, что их можно закэшировать не вникая. Закэшировали запросы к метаданным и сами 10+182=192 пакета.</div><div class=""><br class=""></div><div class="">День N: программисты захотели ещё 1 пакет добавить. Мигрировать на свежие версии предыдущих 10 пакетов (или предыдущих 192, если вместе с зависимостями) не хотят, это отдельное упражнение. </div><div class=""><br class=""></div><div class="">Опять пошли GET-запросы к метаданным, наш новый пакет хочет ещё 5 штук новых и 12 штук из тех, предыдущих 182, но в более свежих версиях, хотя старые тоже подошли бы. Если смогли так обмануть исходный репозиторий, чтобы эти запросы выдали 12 старых пакетов именно в закэшированных версиях, то повезло. А если протокол обращения к репозиторию к этому не пригоден, то не повезло, придётся тащить все 12 новых версий пакетов тоже. Начинается субботник. В JS он частично лечится через packages-lock, в питоне надо немного повозиться, в других языках тоже обязательно надо повозиться.</div><div class=""><br class=""></div><div class="">День M: захотели ещё пакет, наш кэш усердно обманывает, чтобы при ходьбе по зависимостям выдавать, что более свежих версий наших 182 пакетов нету. Но вот новый пакет активно хочет более свежую версию, у него в метаданных прописана совместимость >= n.m.k. Тут новый вид попадалова, когда кэши надо всё-таки выкинуть и всё скачать заново. Причём в этом «всё скачать» исходный репозиторий вам присунет все 182 обновлённых пакета, и ещё пару десятков новых пакетов. А вы хотели выборочно обновить только то, что действительно нужно, а глобальный субботник снова хотели «на потом».</div><div class=""><br class=""></div><div class="">Короче, идея просто кэшировать постепенно превращается в <a href="https://www.youtube.com/watch?v=V5RQh5tNcbo" class="">https://www.youtube.com/watch?v=V5RQh5tNcbo</a></div><div class=""><br class=""></div><div class="">Вообще, всё от постановки задачи зависит. Если «хочу чтоб в военное время можно было кэшированными версиями пакетов сервер залить, понимаю, что новых версий после начала войны брать из-за океана не буду», то простого кэширования достаточно. Если «хочу сам, выборочно вбирать в себя новшества, читая диффы, откладывая на потом странные обновления и втаскивая полезные», то не вникая в логику репозитория этого не сделать.</div><div class=""><br class=""></div><div class="">Влад</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">23 нояб. 2023 г., в 17:24, Eugene Prokopiev <<a href="mailto:eugene.prokopiev@gmail.com" class="">eugene.prokopiev@gmail.com</a>> написал(а):</div><br class="Apple-interchange-newline"><div class=""><div class="">Ну так оглавление, ссылающееся на новые файлы ( а старые при этом<br class="">остаются доступными) - это кажется фичей, а не багом, разве нет?<br class=""><br class="">Другие варианты смотрел, но с монстрами типа artifactory/sonatype<br class="">связываться не хочется (там еще и куча ограничений в свободных<br class="">версиях), а с зоопарком reposilite/devpi/verdaccio тоже<br class=""><br class="">чт, 23 нояб. 2023 г. в 15:22, Vladislav Shabanov <<a href="mailto:vlad.shabanov@gmail.com" class="">vlad.shabanov@gmail.com</a>>:<br class=""><blockquote type="cite" class=""><br class="">Без знания семантики кэшировать непросто. Оглавление начинает ссылаться на новые файлы. Даже если вы кэшируете сами пакеты, метаданные кэшировать сложнее.<br class="">Посмотрите:<br class=""><br class=""><a href="https://verdaccio.org/docs/best" class="">https://verdaccio.org/docs/best</a><br class="">https://www.sonatype.com/products/sonatype-nexus-oss-download<br class=""><br class="">Владислав<br class=""><br class="">23 нояб. 2023 г., в 14:31, Eugene Prokopiev <eugene.prokopiev@gmail.com> написал(а):<br class=""><br class="">Здравствуйте!<br class=""><br class="">Есть задача кэширования репозиториев maven/pypi/npm для разработки - и<br class="">гуглится куча примеров, как это сделать<br class=""><br class="">Но смущает, что во всех примерах используются директивы proxy_cache*,<br class="">а мне более удобным кажется proxy_store - в этом случае кэш<br class="">раскладываются по файлам аналогично оригиналу, понятно где, что и<br class="">сколько места занимает, легко вручную удалить часть кэша и т.д.<br class=""><br class="">Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или<br class="">лучше?) proxy_cache*?<br class=""><br class="">--<br class="">WBR,<br class="">Eugene Prokopiev<br class="">_______________________________________________<br class="">nginx-ru mailing list<br class="">nginx-ru@nginx.org<br class="">https://mailman.nginx.org/mailman/listinfo/nginx-ru<br class=""><br class=""><br class=""></blockquote><br class=""><br class="">-- <br class="">WBR,<br class="">Eugene Prokopiev<br class=""></div></div></blockquote></div><br class=""></div></body></html>