This release is a pre-release and may not be stable for production use.
blueline
A blueline is the printer’s last proof before a job goes to press. blueline is the last proof before a package goes to PyPI.
It builds a project’s sdist and wheel and runs twine check --strict on them with the same Python and the same twine (and readme-renderer, docutils, …) versions that the pinned pypa/gh-action-pypi-publish action uploads with. Anything the real upload would reject fails in a pull request first.
Usage
Pin the action to a full commit SHA in your release workflow:
- uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # v1.14.0
Then run, from the project root, on the Python the action uses:
python -m blueline dry-release --no-dry-run
blueline reads the pin from .github/workflows/release.yml, fetches the action’s Dockerfile and requirements/runtime.txt at that commit, and:
fails if it is not running on the action’s Python (the Dockerfile’s FROM python:X.Y);
installs twine into the running environment with pip, constrained to the action’s runtime pins;
builds an sdist and a wheel into a temporary directory;
runs twine check --strict on them.
Steps 2 and 3 change things, so, like other gather commands, they only run with --no-dry-run; without it, blueline fetches the action’s files, checks the Python version, and logs the commands it would run.
--workflow PATH reads the pin from another workflow file, and a positional argument builds a project other than the current directory.
Every command runs through gather’s runner. curl for the action’s files, the version check, and twine check are read-only and use safe_run; pip and build use run, which only runs them with --no-dry-run. Tests drive the whole command with a fake subprocess.run.
With nox
@nox.session(python="3.13")
def dry_release(session):
session.install("blueline")
session.run("python", "-m", "blueline", "dry-release", "--no-dry-run")
When the action moves to a new Python, blueline fails and says so: update python= and the CI job that runs the session.
blueline needs pip in the session’s environment, which nox’s default virtualenv backend provides. The uv backend is not supported. It also needs curl on PATH, which GitHub’s runners have.
Metadata
Release files for blueline 2026.10.23.1909.dev1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| blueline-2026.10.23.1909.dev1-py3-none-any.whl | Python 3 | none | any | Details |
Release files / blueline-2026.10.23.1909.dev1-py3-none-any.whl
| Download URL | blueline-2026.10.23.1909.dev1-py3-none-any.whl |
|---|---|
| Size | 17.0 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
2bb041224d0987227dd9e3803856c3b862597c5d0be9a8ce4f98f327b014ebe6
|
|
BLAKE2b-256 checksum How to use checksums |
68877e06855dd19eb16ff0425a04a07008fbb1240fdba91ca8e5d15bec47b4a1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.8
|
Security for blueline 2026.10.23.1909.dev1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.