twine man page

twine — twine Documentation

Table of Contents

Twine User Documentation

Twine is a utility for publishing packages on PyPI.

Currently it only supports registering projects and uploading distributions.

Why Should I Use This?

The goal of twine is to improve PyPI interaction by improving security and testability.

The biggest reason to use twine is that it securely authenticates you to PyPI over HTTPS using a verified connection, while python setup.py upload only recently stopped using HTTP in Python 2.7.9+ and Python 3.2+. This means anytime you use python setup.py upload with an older Python version, you expose your username and password to being easily sniffed. Twine uses only verified TLS to upload to PyPI, protecting your credentials from theft.

Secondly, it allows you to precreate your distribution files. python setup.py upload only allows you to upload something that you've created in the same command invocation. This means that you cannot test the exact file you're going to upload to PyPI to ensure that it works before uploading it.

Finally, it allows you to pre-sign your files and pass the .asc files into the command line invocation (twine upload twine-1.0.1.tar.gz twine-1.0.1.tar.gz.asc). This enables you to be assured that you're typing your gpg passphrase into gpg itself and not anything else, since you will be the one directly executing gpg --detach-sign -a <filename>.

Features

Installation

$ pip install twine

Usage

1.

Create some distributions in the normal way:

$ python setup.py sdist bdist_wheel
2.

Upload with twine:

$ twine upload dist/*
3.

Done!

More documentation on using twine to upload packages to PyPI is in the Python Packaging User Guide.

Options

$ twine upload -h

usage: twine upload [-h] [-r REPOSITORY] [--repository-url REPOSITORY_URL]
                    [-s] [--sign-with SIGN_WITH] [-i IDENTITY] [-u USERNAME]
                    [-p PASSWORD] [-c COMMENT] [--config-file CONFIG_FILE]
                    [--skip-existing] [--cert path] [--client-cert path]
                    dist [dist ...]

positional arguments:
  dist                  The distribution files to upload to the repository,
                        may additionally contain a .asc file to include an
                        existing signature with the file upload

optional arguments:
  -h, --help            show this help message and exit
  -r REPOSITORY, --repository REPOSITORY
                        The repository to upload the package to. Can be a
                        section in the config file or a full URL to the
                        repository (default: pypi). (Can also be set via
                        TWINE_REPOSITORY environment variable)
  --repository-url REPOSITORY_URL
                        The repository URL to upload the package to. This can
                        be specified with --repository because it will be used
                        if there is no configuration for the value passed to
                        --repository. (Can also be set via
                        TWINE_REPOSITORY_URL environment variable.)
  -s, --sign            Sign files to upload using gpg
  --sign-with SIGN_WITH
                        GPG program used to sign uploads (default: gpg)
  -i IDENTITY, --identity IDENTITY
                        GPG identity used to sign files
  -u USERNAME, --username USERNAME
                        The username to authenticate to the repository as (can
                        also be set via TWINE_USERNAME environment variable)
  -p PASSWORD, --password PASSWORD
                        The password to authenticate to the repository with
                        (can also be set via TWINE_PASSWORD environment
                        variable)
  -c COMMENT, --comment COMMENT
                        The comment to include with the distribution file
  --config-file CONFIG_FILE
                        The .pypirc config file to use
  --skip-existing       Continue uploading files if one already exists. (Only
                        valid when uploading to PyPI. Other implementations
                        may not support this.)
  --cert path           Path to alternate CA bundle (can also be set via
                        TWINE_CERT environment variable)
  --client-cert path    Path to SSL client certificate, a single file
                        containing the private key and the certificate in PEM
                        format

Twine also includes a register command.

WARNING:

register is no longer necessary if you are uploading to pypi.org. As such, it is no longer supported in Warehouse (the new PyPI software running on pypi.org). However, you may need this if you are using a different package index.

For completeness, its usage:

$ twine register -h
usage: twine register [-h] [-r REPOSITORY] [--repository-url REPOSITORY_URL]
                      [-u USERNAME] [-p PASSWORD] [-c COMMENT]
                      [--config-file CONFIG_FILE] [--cert path]
                      [--client-cert path]
                      package

positional arguments:
  package               File from which we read the package metadata

optional arguments:
  -h, --help            show this help message and exit
  -r REPOSITORY, --repository REPOSITORY
                        The repository to register the package to. Can be a
                        section in the config file or a full URL to the
                        repository (default: pypi). (Can also be set via
                        TWINE_REPOSITORY environment variable)
  --repository-url REPOSITORY_URL
                        The repository URL to upload the package to. This can
                        be specified with --repository because it will be used
                        if there is no configuration for the value passed to
                        --repository. (Can also be set via
                        TWINE_REPOSITORY_URL environment variable.)
  -u USERNAME, --username USERNAME
                        The username to authenticate to the repository as (can
                        also be set via TWINE_USERNAME environment variable)
  -p PASSWORD, --password PASSWORD
                        The password to authenticate to the repository with
                        (can also be set via TWINE_PASSWORD environment
                        variable)
  -c COMMENT, --comment COMMENT
                        The comment to include with the distribution file
  --config-file CONFIG_FILE
                        The .pypirc config file to use
  --cert path           Path to alternate CA bundle (can also be set via
                        TWINE_CERT environment variable)
  --client-cert path    Path to SSL client certificate, a single file
                        containing the private key and the certificate in PEM
                        format

Environment Variables

Twine also supports configuration via environment variables. Options passed on the command line will take precedence over options set via environment variables. Definition via environment variable is helpful in environments where it is not convenient to create a .pypirc file, such as a CI/build server, for example.

  • TWINE_USERNAME - the username to use for authentication to the repository
  • TWINE_PASSWORD - the password to use for authentication to the repository
  • TWINE_REPOSITORY - the repository configuration, either defined as a section in .pypirc or provided as a full URL
  • TWINE_REPOSITORY_URL - the repository URL to use
  • TWINE_CERT - custom CA certificate to use for repositories with self-signed or untrusted certificates

Resources

Contributing

See our developer documentation for how to get started, an architectural overview, and our future development plans.

Code of Conduct

Everyone interacting in the twine project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the PyPA Code of Conduct.

Contributing

We are happy you have decided to contribute to twine.

Please see the GitHub repository for code and more documentation, and the official Python Packaging User Guide for user documentation. You can also join #pypa or #pypa-dev on Freenode, or the pypa-dev mailing list, to ask questions or get involved.

Getting started

We recommend you use a development environment. Using a virtualenv keeps your development environment isolated, so that twine and its dependencies do not interfere with packages already installed on your machine.  You can use virtualenv or pipenv to isolate your development environment.

Clone the twine repository from GitHub, and then make and activate your virtual environment, using Python 3.6 as the Python version in the virtual environment. Example:

mkvirtualenv -p /usr/bin/python3.6 twine

Then, run the following command:

pip install -e /path/to/your/local/twine

Now, in your virtual environment, twine is pointing at your local copy, so when you have made changes, you can easily see their effect.

Building the documentation

Additions and edits to twine's documentation are welcome and appreciated.

We use tox to build docs. Activate your virtual environment, then install tox.

pip install tox

If you are using pipenv to manage your virtual environment, you may need the tox-pipenv plugin so that tox can use pipenv environments instead of virtualenvs.

To build the docs locally using tox, activate your virtual environment, then run:

tox -e docs

The HTML of the docs will be visible in twine/docs/_build/.

When you have made your changes to the docs, please lint them before making a pull request. To run the linter from the root directory:

doc8 docs

Testing

Tests with twine are run using tox, and tested against the following Python versions: 2.7, 3.4, 3,5, and 3.6. To run these tests locally, you will need to have these versions of Python installed on your machine.

Either use tox to build against all supported Python versions (if you have them installed) or use tox -e py{version} to test against a specific version, e.g., tox -e py27 or tox -e py34.

Also, always run tox -e pep8 before submitting a pull request.

Submitting changes

1.

Fork the GitHub repository.

2.

Make a branch off of master and commit your changes to it.

3.

Run the tests with tox and lint any docs changes with doc8.

4.

Ensure that your name is added to the end of the AUTHORS file using the format Name <email@domain.com> (url), where the (url) portion is optional.

5.

Submit a Pull Request to the master branch on GitHub.

Architectural overview

Twine is a command-line tool for interacting with PyPI securely over HTTPS. Its command line arguments are parsed in twine/cli.py. Currently, twine has two principal functions: uploading new packages and registering new projects. The code for registering new projects is in twine/commands/register.py, and the code for uploading is in twine/commands/upload.py. The file twine/package.py contains a single class, PackageFile, which hashes the project files and extracts their metadata. The file twine/repository.py contains the Repository class, whose methods control the URL the package is uploaded to (which the user can specify either as a default, in the .pypirc file, or pass on the command line), and the methods that upload the package securely to a URL.

Future development

See our open issues.

In the future, pip and twine may merge into a single tool; see ongoing discussion.

Changelog

  • #256: Improve progressbar
  • #257: Declare support for Python 3.6
  • #303: Revise docs predicting future of twine
  • #296: Add architecture overview to docs
  • #295: Add doc building instructions
  • #46: Link to changelog from README
  • #304: Reorganize & improve user & developer documentation.
  • #265: Fix --repository[-url] help text
  • #268: Print progress to stdout, not stderr
  • #297: Fix Read the Docs, tox, Travis configuration
  • #286: Fix Travis CI and test configuration
  • #200: Remove obsolete registration guidance
  • #299: Fix changelog formatting
  • #298: Fix syntax highlighting in README
  • #315: Degrade gracefully when keyring is unavailable
  • :  Blacklist known bad versions of Requests. See also  #253:
  • :  Check if a package exists if the URL is one of:

  • :  Fix precedence of --repository-url over --repository. See also  #206:
  • :  Fix --skip-existing when used to upload a package for the first time.  See also  #220:
  • :  Twine sends less information about the user's system in the User-Agent string. See also  #229:
  • :  Twine will use hashlib.blake2b on Python 3.6+ instead of using pyblake2 for Blake2 hashes 256 bit hashes.
  • :  Twine will now resolve passwords using the keyring if available. Module can be required with the keyring extra.
  • #171: Generate Blake2b 256 digests for packages if pyblake2 is installed. Users can use python -m pip install twine[with-blake2] to have pyblake2 installed with Twine.
  • #166: Allow the Repository URL to be provided on the command-line (--repository-url) or via an environment variable (TWINE_REPOSITORY_URL).
  • #144: Retrieve configuration from the environment as a default.

    • Repository URL will default to TWINE_REPOSITORY
    • Username will default to TWINE_USERNAME
    • Password will default to TWINE_PASSWORD
  • #201: Switch from upload.pypi.io to upload.pypi.org.
  • :  Do not generate traffic to Legacy PyPI unless we're uploading to it or uploading to Warehouse (e.g., pypi.io). This avoids the attempt to upload a package to the index if we can find it on Legacy PyPI already.
  • :  Warn users if they receive a 500 error when uploading to *pypi.python.org
  • :  Stop testing on Python 2.6. 2.6 support will be "best effort" until 2.0.0
  • :  Generate SHA256 digest for all packages by default.
  • :  Correct a packaging error.
  • #195: Fix uploads to instances of pypiserver using --skip-existing. We were not properly checking the return status code on the response after attempting an upload.
  • #189:,  #191: Fix issue where we were checking the existence of packages even if the user didn't specify --skip-existing.
  • #187: Clint was not specified in the wheel metadata as a dependency.
  • #177: Switch Twine to upload to pypi.io instead of pypi.python.org.
  • #167: Implement retries when the CDN in front of PyPI gives us a 5xx error.
  • #162: Allow --skip-existing to work for 409 status codes.
  • #152: Add progress bar to uploads.
  • #142: Support --cert and --client-cert command-line flags and config file options for feature parity with pip. This allows users to verify connections to servers other than PyPI (e.g., local package repositories) with different certificates.
  • #186: Allow passwords to have %s in them.
  • #155: Bump requests-toolbelt version to ensure we avoid ConnectionErrors
  • #146: Exception while accessing the respository key (sic) when raising a redirect exception.
  • #145: Paths with hyphens in them break the Wheel regular expression.
  • #137:,  #140: Uploading signatures was broken due to the pull request that added large file support via requests-toolbelt. This caused a 500 error on PyPI and prevented package and signature upload in twine 1.6.0
  • #132: Upload signatures with packages appropriately

    As part of the refactor for the 1.6.0 release, we were using the wrong name to find the signature file.

    This also uncovered a bug where if you're using twine in a situation where * is not expanded by your shell, we might also miss uploading signatures to PyPI. Both were fixed as part of this.

  • #130: Fix signing support for uploads
  • #8: Support registering new packages with twine register
  • #115: Add the --skip-existing flag to twine upload to allow users to skip releases that already exist on PyPI.
  • #97: Allow the user to specify the location of their .pypirc
  • #104: Large file support via the requests-toolbelt
  • #106: Upload wheels first to PyPI
  • #111: Provide more helpful messages if .pypirc is out of date.
  • #116: Work around problems with Windows when using getpass.getpass
  • #114: Warnings triggered by pkginfo searching for PKG-INFO files should no longer be user visible.
  • #92: Raise an exception on redirects
  • #29: Support commands not named "gpg" for signing
  • #61: Support deprecated pypirc file format
  • #85: Display information about the version of setuptools installed
  • :  Add lower-limit to requests dependency
  • #6: Switch to a git style dispatching for the commands to enable simpler commands and programmatic invocation.
  • #13: Parse ~/.pypirc ourselves and use subprocess instead of the distutils.spawn module.
  • #65: Expand globs and check for existence of dists to upload
  • #26: Add support for uploading Windows installers
  • #47: Fix issue uploading packages with _s in the name
  • #32: Use pkg_resources to load registered commands
  • #34: List registered commands in help text
  • #28: Prevent ResourceWarning from being shown
  • :  Additional functionality.
  • :  Basic functionality.
  • search

Author

Donald Stufft, Individual contributors

Info

Mar 17, 2018 1.10 twine