Ну, как устроена реальная жизнь: День 1: программисты хотят 10 пакетов, вместе с зависимостями это, допустим, 182 штуки. Во время «вместе с зависимостями» было сколько-то обращений к оглавлению за метаданными. Допустим, они все GET и настолько простые, что их можно закэшировать не вникая. Закэшировали запросы к метаданным и сами 10+182=192 пакета.
День N: программисты захотели ещё 1 пакет добавить. Мигрировать на свежие версии предыдущих 10 пакетов (или предыдущих 192, если вместе с зависимостями) не хотят, это отдельное упражнение. Опять пошли GET-запросы к метаданным, наш новый пакет хочет ещё 5 штук новых и 12 штук из тех, предыдущих 182, но в более свежих версиях, хотя старые тоже подошли бы. Если смогли так обмануть исходный репозиторий, чтобы эти запросы выдали 12 старых пакетов именно в закэшированных версиях, то повезло. А если протокол обращения к репозиторию к этому не пригоден, то не повезло, придётся тащить все 12 новых версий пакетов тоже. Начинается субботник. В JS он частично лечится через packages-lock, в питоне надо немного повозиться, в других языках тоже обязательно надо повозиться. День M: захотели ещё пакет, наш кэш усердно обманывает, чтобы при ходьбе по зависимостям выдавать, что более свежих версий наших 182 пакетов нету. Но вот новый пакет активно хочет более свежую версию, у него в метаданных прописана совместимость >= n.m.k. Тут новый вид попадалова, когда кэши надо всё-таки выкинуть и всё скачать заново. Причём в этом «всё скачать» исходный репозиторий вам присунет все 182 обновлённых пакета, и ещё пару десятков новых пакетов. А вы хотели выборочно обновить только то, что действительно нужно, а глобальный субботник снова хотели «на потом». Короче, идея просто кэшировать постепенно превращается в https://www.youtube.com/watch?v=V5RQh5tNcbo <https://www.youtube.com/watch?v=V5RQh5tNcbo> Вообще, всё от постановки задачи зависит. Если «хочу чтоб в военное время можно было кэшированными версиями пакетов сервер залить, понимаю, что новых версий после начала войны брать из-за океана не буду», то простого кэширования достаточно. Если «хочу сам, выборочно вбирать в себя новшества, читая диффы, откладывая на потом странные обновления и втаскивая полезные», то не вникая в логику репозитория этого не сделать. Влад > 23 нояб. 2023 г., в 17:24, Eugene Prokopiev <eugene.prokop...@gmail.com> > написал(а): > > Ну так оглавление, ссылающееся на новые файлы ( а старые при этом > остаются доступными) - это кажется фичей, а не багом, разве нет? > > Другие варианты смотрел, но с монстрами типа artifactory/sonatype > связываться не хочется (там еще и куча ограничений в свободных > версиях), а с зоопарком reposilite/devpi/verdaccio тоже > > чт, 23 нояб. 2023 г. в 15:22, Vladislav Shabanov <vlad.shaba...@gmail.com>: >> >> Без знания семантики кэшировать непросто. Оглавление начинает ссылаться на >> новые файлы. Даже если вы кэшируете сами пакеты, метаданные кэшировать >> сложнее. >> Посмотрите: >> >> https://verdaccio.org/docs/best >> https://www.sonatype.com/products/sonatype-nexus-oss-download >> >> Владислав >> >> 23 нояб. 2023 г., в 14:31, Eugene Prokopiev <eugene.prokop...@gmail.com> >> написал(а): >> >> Здравствуйте! >> >> Есть задача кэширования репозиториев maven/pypi/npm для разработки - и >> гуглится куча примеров, как это сделать >> >> Но смущает, что во всех примерах используются директивы proxy_cache*, >> а мне более удобным кажется proxy_store - в этом случае кэш >> раскладываются по файлам аналогично оригиналу, понятно где, что и >> сколько места занимает, легко вручную удалить часть кэша и т.д. >> >> Расскажите, какие минусы у этого подхода, чем proxy_store хуже (или >> лучше?) proxy_cache*? >> >> -- >> WBR, >> Eugene Prokopiev >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru@nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> > > > -- > WBR, > Eugene Prokopiev
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
