Controlling package uploads
The command flit publish
will upload your package to a package index server.
The default settings let you upload to PyPI,
the default Python Package Index, with a single user account.
If you want to upload to other servers, or with more than one user account, or upload packages from a continuous integration job, you can configure Flit in two main ways:
Using .pypirc
You can create or edit a config file in your home directory, ~/.pypirc
that
will be used by default or you can specify a custom location.
This is also used by other Python tools such as twine.
For instance, to upload a package to the Test PyPI server instead of the normal PyPI, use a config file looking like this:
[distutils]
index-servers =
pypi
testpypi
[pypi]
repository = https://upload.pypi.org/legacy/
username = sirrobin # Replace with your PyPI username
[testpypi]
repository = https://test.pypi.org/legacy/
username = sirrobin # Replace with your TestPyPI username
You can select an index server from this config file with the
--repository
option:
flit publish --repository testpypi
If you don’t use this option,
Flit will use the server called pypi
in the config file. If that doesn’t
exist, it uploads to PyPI at https://upload.pypi.org/legacy/
by default.
If you publish a package and you don’t have a .pypirc
file, Flit will create
it to store your username.
Flit tries to store your password securely using the
keyring library.
If keyring is not installed, Flit will ask for your password for each upload.
Alternatively, you can also manually add your password to the .pypirc
file
(password = ...
)
Using environment variables
You can specify a server to upload to with FLIT_INDEX_URL
, and
pass credentials with FLIT_USERNAME
and FLIT_PASSWORD
.
Environment variables take precedence over the config file, except if you use
the --repository
option to explicitly pick a server from the config file.
This can make it easier to automate uploads, for example to release packages from a continuous integration job.
Warning
Storing a password in an environment variable is convenient, but it’s easy to accidentally leak it. Look out for scripts that helpfully print all environment variables for debugging, and remember that other scripts and libraries you run in that environment have access to your password.