使用 Homebrew, apk, apt, dnf, MacPorts, Nix, pacman, scoop, winget 安装 twine

项目链接

• 主页
• 上游文档
• 软件包管理器页面

命令和别名

• twine

项目历史

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.

采用历史

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.

使用方式

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.

为什么软件包爱好者会关心

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.

时间线

• 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.

来源

• 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/