GitXplorerGitXplorer
h

nginx_pypi_cache

public
29 stars
8 forks
2 issues

Commits

List of commits on branch master.
Verified
4d0d78e473e53c6ee609e3d89781455c71bac7ab

Test against uv, improve test cleanup (#4)

hhauntsaninja committed 9 months ago
Verified
196937f1e80a0dd0a09b4f41de1fa4d7dfbf5f1f

Set proxy_ssl_name in simple (#3)

hhauntsaninja committed 9 months ago
Unverified
543405b16b8135fbcaecac5ff2181e93f9d3311c

test with latest pip

hhauntsaninja committed a year ago
Unverified
7df5b6f2f7f551e31305e67d56cc223089d96ac7

hello world

hhauntsaninja committed 2 years ago

README

The README file for this repository.

pypi_nginx_cache

A PyPI cache using nginx.

Usage

This serves as a caching mirror for PyPI. It's a simple stateless service and does not support uploading packages / private indices. For this use case, I've found it to be significantly faster and significantly more reliable than devpi.

To run it locally:

docker run -p 80:80 --rm $(docker build -q .)

To tell pip to connect to this instead of pypi.org, use:

pip install --index-url=http://localhost/simple mypy

or

export PIP_INDEX_URL=http://localhost/simple
pip install mypy

Github container registry

To pull the latest version from the Github container registry:

docker pull ghcr.io/hauntsaninja/nginx_pypi_cache:latest

See https://github.com/hauntsaninja/nginx_pypi_cache/pkgs/container/nginx_pypi_cache

Troubleshooting

It turns out it's surprisingly easy to mess something up and not actually end up proxying requests. tests/mitmtest.sh should help confirm that we're hitting the cache when we expect to, instead of hitting upstream PyPI.

The log messages are also pretty useful (check nginx.conf to see exactly what these correspond to):

172.17.0.1 - localhost [13/Jan/2023:02:36:00 +0000] request_time=0.000 upstream_time=- cache_status=HIT 	200 "GET /simple/mypy/ HTTP/1.1" 78368