The idea is really simple. You give it a package name. It gives you a badge. This badge has live information from the PyPI JSON API. It shows you the version of the package the license it uses what version of Python it. When it was last updated. You also get to see how times it has been downloaded, thanks to pypistats. This is like what nodei.co does. It is, for Python packages. The goal is to make it work well and not use much memory so it can load fast and store information for a while.
Example: https://pythonico.leapcell.app/pypi/requests.svg
The service is made using FastAPI and asynchronous requests. It creates SVG images as needed and stores them in a cache. This way it does not keep asking the APIs for the same information over and over.
The main idea was to make the service simple: it does not require users to have accounts it does not track users it just gives you a FastAPI SVG endpoint that always returns the result for the same input. You can easily add this service to a README file, on a website. The service is a deterministic FastAPI SVG endpoint.
Repo (GPL-3.0): https://github.com/livrasand/PythonICO
Some implementation details that might be interesting:
* Async fetching of PyPI + download stats
* Simple in-memory cache with TTL (Redis support is on the roadmap)
* Pure SVG output (no PNG conversion step)
* Parameter parsing designed to be order-sensitive for badge composition
This started as a tool because I wanted more control, over how PyPI stats appear in READMEs especially when it comes to multi-field badges and the way they are ordered. I would appreciate feedback on PyPI stats. How they can be made to look better in READMEs particularly the multi-field badges and the ordering of PyPI stats.
* API design (is the query param model reasonable?)
* Caching strategy (better approach than simple TTL?)
* I am wondering if this thing should be something that we can send out to people as a package rather than just a service that we host on our own system. This means that people can use the package on their own without having to connect to our service all the time. The package would have everything that the service has and people can install it on their machines. This is different, from the hosted service, where we're the ones who take care of everything and people just use it through the internet.
* Are there any obvious problems with this that I am not seeing, like something that could be used in a bad way or something that could get really big and cause issues with the system I mean any obvious abuse or scaling concerns that I might be missing with the system and its potential, for abuse or scaling concerns.
Happy to hear criticism or suggestions.
