PyPI packages on any website.

PyPI is operated and maintained by the Python Software Foundation (PSF), the non-profit that also stewards the CPython reference implementation, the language reference, and the broader Python community infrastructure. The current PyPI codebase is called Warehouse, an open-source from-scratch rewrite released in production in April 2018 to replace legacy PyPI (also called Cheeseshop). Warehouse runs in the open at github.com/pypi/warehouse under the Apache 2.0 license, and the API surface, content model, security model, and operational practices are documented publicly. This is unusual for a package registry of this scale and it matters enormously for widget tooling. Where some commercial registries rely on undocumented internal endpoints, Warehouse ships a stable documented public JSON API at pypi.org/pypi/{project}/json covering project metadata, version history, classifiers, project URLs, and the full file list including wheels and sdists. Standard XML-RPC and Simple Repository (PEP 503) endpoints are also available as official integration paths. The API is rate-limited generously for unauthenticated public read access and explicitly supported for third-party tooling, including widgets like this one. PSF stewardship also means PyPI prioritizes the long-term stability of the API contract over short-term redesigns, which is the durable reason a PyPI widget stays working when other registry-platform widgets break: the contract is in the open, the codebase is in the open, and the Python community itself has a stake in keeping the integration path stable.

Asking how many downloads a Python package has is one of the first questions any visitor asks, and PyPI answers it through a deliberately indirect path. PyPI does not expose live download counters on the JSON API or in the package landing page, and this is by design. Live counters create a powerful incentive for scrape-driven inflation, and PyPI's stewardship team chose to publish the raw download logs to a public BigQuery dataset instead, at bigquery-public-data.pypi.file_downloads. Anyone can query the dataset directly with SQL, and tools like pepy.tech and pypistats.org wrap that data with a friendlier API and visualization layer. Poper queries the BigQuery dataset on a daily refresh cycle and renders rolling 30-day, 90-day, and all-time counts per package, plus per-release sparklines so visitors see download velocity over time, not just a static cumulative total. This matters because cumulative downloads are a vanity metric for a five-year-old package and a growth indicator for a five-month-old one. The download dataset includes user agent and Python version metadata as well, so future versions of the widget will surface install ratios per Python version (a project that gets 80% of installs from Python 3.12 vs one that gets 30% from Python 3.8 should plan support windows differently). For now, the widget renders the headline counts that visitors recognize as adoption signals: monthly downloads, weekly downloads, and the percent change since last period. Combined with the pip install snippet rendered alongside, the embedded card converts visitors into installers more reliably than any combination of marketing copy.

Python packaging has its own conventions that differ from JavaScript, Ruby, or Go in real, load-bearing ways. Versions follow PEP 440 rather than semver, with formal support for pre-release segments (1.0a1, 1.0rc2), post-release segments (1.0.post1), dev release segments (1.0.dev3), local version identifiers (1.0+ubuntu1), and even an optional epoch (2!1.0). A widget that uses naive lexicographic sort or assumes semver will misorder versions in ways that confuse users and bury active releases under stale ones. Poper parses every version through PEP 440 semantics, sorts releases correctly, and exposes pre-release filtering so a project can show only stable releases on the marketing site while showing the full release history on the developer docs. Yanked releases are filtered by default. The widget also surfaces wheel platform tags from the file list, which is critical for projects that ship native code. A scientific computing package shipping wheels for cp312-abi3-manylinux2014_x86_64, cp312-abi3-macosx_11_0_arm64, and cp312-abi3-win_amd64 is a project that visitors can pip install today on every modern platform, and surfacing that fact builds trust the way no badge can. Trove classifiers are the official PyPI taxonomy, with categories for development status, intended audience, license, operating system, programming language, topic, and framework. Classifiers serve the same role tags serve on Dev.to or topics serve on GitHub: they tell visitors at a glance what the package is for. Poper renders classifier pills natively, with sensible defaults for which classifier categories to surface (Topic, Framework, Intended Audience by default) and full controls in the visual editor to surface more or fewer. Project URLs from PyPI metadata become URL chips for Homepage, Source, Documentation, Issues, and Funding, so a single embedded card replaces the half-dozen links a project would otherwise need to spell out manually next to every install snippet.

Supply-chain security has become a first-order concern in the Python ecosystem, and PyPI has been a leader in shipping verifiable provenance through 2024 and 2025. PEP 740, published in early 2024, defines a standard for digitally signed publish attestations on PyPI using the Sigstore transparency log. When a package author publishes a release built with Trusted Publishing on a CI provider that supports it (GitHub Actions, GitLab CI, and others), the upload now includes a cryptographically verifiable attestation proving which workflow built the wheel and from which Git commit. Anyone can verify that attestation against the public Sigstore Rekor transparency log without trusting PyPI itself. This is a meaningful step beyond the npm provenance model and beyond the gem-signing approach RubyGems uses, because the Sigstore root of trust is operated independently of the registry. PyPI exposes attestation metadata on the JSON API, and Poper renders an attestation badge on every release that has one, with a link to the verification flow for users who want to audit the chain. For widget consumers this is the supply-chain signal that matters in 2026: a package displaying live PyPI provenance attestations next to the pip install snippet is a package an enterprise security team can adopt without a separate review cycle. The widget will continue to track the evolving PEP 740 ecosystem, including the Trusted Publishing registry of supported CI providers, and surface attestation richness as the standard matures.

Compared to npm, PyPI is smaller in raw package count (roughly 600,000 projects vs npm's several million) but materially deeper per package: scientific computing libraries like NumPy, SciPy, scikit-learn, Pandas, and PyTorch each see weekly downloads on the order of tens of millions and ship genuinely stable, decade-plus public APIs. Compared to RubyGems, PyPI is larger and more diverse across domains: web frameworks, machine learning, data engineering, scientific computing, devops tooling, and academic research software all coexist on the same registry. The PyData ecosystem alone represents a category that has no clean equivalent on any other registry, with NumPy and Pandas serving as the foundational layer for scikit-learn, Pandas, statsmodels, scikit-image, scipy, sympy, networkx, dask, polars, and dozens of domain-specific scientific packages on top. For a widget, this means the audience for a PyPI embed is unusually diverse: academic labs publishing research software, data science consultants showcasing ML libraries, scientific computing maintainers documenting numerical libraries, web framework authors marketing alternatives to Django and Flask, and devops tooling builders demonstrating their CI plugin uptake. Poper supports all five buyer types out of the box, with layout presets tuned for each. SEO etiquette for embedded PyPI content is the same etiquette that applies to embedding any third-party content: emit canonical URLs pointing back to pypi.org, use SoftwareApplication or Article JSON-LD for structured data, and let visitors click through to the original PyPI page when they want full release notes or contributor lists. Poper handles all three automatically, and the result is an embedded card that builds trust without competing against the canonical PyPI page for the same query. Combined with the asynchronous loading and global CDN edge caching that keeps the widget under 40KB gzipped and lazy-loaded below the fold, the performance and SEO posture of a PyPI feed widget is among the cleanest of any embeddable package widget on the market in 2026.