Install twine with Homebrew, apk, apt, dnf, MacPorts, Nix, pacman, scoop, winget

Project links

• Homepage
• Upstream docs
• Package manager page

Commands and aliases

• twine

Project history

Twine was created to separate package building from package uploading and to make PyPI uploads safer and more testable. Its documentation contrasts it with `python setup.py upload`, emphasizing verified HTTPS, uploading already-built artifacts, and support for wheels and source distributions.

The changelog records a long-running 1.x series through the 2010s, a 2.0 release in 2019 that required Python 3.6 or later, 3.x releases that improved non-interactive and keyring behavior, and modern 5.x/6.x work around metadata validation, PyPI token handling, trusted publishing, and removal of older distribution formats.

Adoption history

Twine's adoption tracks the modernization of Python packaging. As PyPI, Warehouse, wheels, API tokens, and build-system-independent packaging became normal, Twine became the familiar upload command in release checklists, CI jobs, and packaging tutorials.

Its package-manager presence is broad: the input facts show it packaged by Homebrew, Debian, Ubuntu, Fedora/dnf, Arch/pacman, MacPorts, Nix, Scoop, and other ecosystems. That breadth reflects its role as infrastructure for publishing other packages, not as an end-user application.

How it is used

The standard workflow is to build distributions, test against TestPyPI if needed, and run `twine upload dist/*`. Twine can read repository and credential information from `.pypirc` or environment variables, prompt interactively, and upload source distributions, wheels, signatures, and newer attestations depending on version.

Package maintainers also use `twine check` to validate distribution metadata and README rendering before upload. In CI, Twine is commonly configured with tokens, trusted publishing, or repository URLs for private Python indexes.

Why package nerds care

Twine is package-nerd infrastructure in the purest sense: it exists so other packages can be published predictably. It codified the split between build artifacts and upload transport, which made Python release automation easier to audit and script.

It also captures the Python ecosystem's security migration: away from legacy `setup.py upload` workflows and toward HTTPS, API tokens, keyring integration, metadata validation, and trusted publishing.

Timeline

• 2010s: Twine 1.x establishes the build-then-upload PyPI workflow.
• 2019-09-24: Twine 2.0.0 requires Python 3.6 or later.
• 2019-2022: Twine 3.x and 4.x improve authentication, non-interactive use, metadata handling, and modern Python support.
• 2024-2025: Twine 5.x and 6.x remove older formats and add work around token defaults, trusted publishing, and refreshed short-lived tokens.

Related projects

• PyPI and Warehouse are Twine's primary public upload targets.
• `python -m build`, setuptools, wheels, and source distributions form the artifact side of the workflow Twine uploads.
• The Python Packaging User Guide and PyPA recommendations helped make Twine part of standard Python release practice.

Sources

• Official GitHub repository: https://github.com/pypa/twine
• Official changelog: https://twine.readthedocs.io/en/stable/changelog.html
• Official documentation: https://twine.readthedocs.io/en/stable/
• PyPI project page: https://pypi.org/project/twine/