Ну, как устроена реальная жизнь:

День 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.prokopiev@gmail.com> написал(а):
>
> Ну так оглавление, ссылающееся на новые файлы ( а старые при этом
> остаются доступными) - это кажется фичей, а не багом, разве нет?
>
> Другие варианты смотрел, но с монстрами типа artifactory/sonatype
> связываться не хочется (там еще и куча ограничений в свободных
> версиях), а с зоопарком reposilite/devpi/verdaccio тоже
>
> чт, 23 нояб. 2023 г. в 15:22, Vladislav Shabanov <vlad.shabanov@gmail.com>:
>>
>> Без знания семантики кэшировать непросто. Оглавление начинает ссылаться на новые файлы. Даже если вы кэшируете сами пакеты, метаданные кэшировать сложнее.
>> Посмотрите:
>>
>> https://verdaccio.org/docs/best
>> https://www.sonatype.com/products/sonatype-nexus-oss-download
>>
>> Владислав
>>
>> 23 нояб. 2023 г., в 14:31, Eugene Prokopiev <eugene.prokopiev@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