My PyPI Release Checklist

pypi-release-checklist.md

• Update HISTORY.md
• Commit the changes:

git add HISTORY.md
git commit -m "Changelog for upcoming release 0.1.1."

• Update version number (can also be minor or major)

bumpversion patch

• Install the package again for local development, but with the new version number:

python setup.py develop

• Run the tests:

tox

• Submit a pull request with the history and version number changes. Have it reviewed and merged.
• Release on PyPI by uploading both sdist and wheel:

python setup.py sdist upload
python setup.py bdist_wheel upload

• Test that it pip installs:

mktmpenv
pip install my_project
<try out my_project>
deactivate

• Push: git push
• Push tags: git push --tags
• Check the PyPI listing page to make sure that the README, release notes, and roadmap display properly. If not, copy and paste the RestructuredText into http://rst.ninjs.org/ to find out what broke the formatting.
• Edit the release on GitHub (e.g. https://github.com/audreyr/cookiecutter/releases). Paste the release notes into the release's release page, and come up with a title for the release.

tox already builds and installs an sdist (unless you tell it not to), so you could simplify this a little bit.

You can check for ReST errors before making a release with python setup.py --long-description | rst2html, or by running restview --long-description --strict.

I've a checklist very much like yours that I've tried to automate as much as I can, so I can do a make release when I'm tired and not mess things up. Thank you for sharing yours!

You might want to upload to PyPi as wheel format.

Thanks so much for this, @audreyr! You're a 🌟!

I've added a separate reminder to register if this is a first release:

python setup.py register -r pypi

(since otherwise a setup.py sdist upload will, rightly, yield a 403).

I'm trying out a simplified checklist (https://gist.github.com/audreyr/9f1564ea049c14f682f4) -- will be bringing that into here soon most likely.

The simplified checklist is now in.

Also good catch @chrisvoncsefalvay about registering the package if it's the 1st release.

Awesome, straight to the point, checklist.

Wouldn't you want to bump the version up before committing?

Awesome checklist. Thanks for this and the wonderful https://github.com/audreyr/cookiecutter-pypackage.
some remarks from the perspective of a pypi noob.

PyPI's own doc is quite comprehensive @ [https://python-packaging-user-guide.readthedocs.org/en/latest/distributing/](Packaging and Distributing Project)

They suggest you can use their test repo https://wiki.python.org/moin/TestPyPI before working on the actual pypi repo. Worked very well for me.
They also advise using twine rather than setup.py upload (or setup.py register for that matter). Reason is cleartext credentials on the wire. Additionally, twine lets you build the dists locally before uploading.

So the workflow is:
python setup.py bdist sdist

Upload to pypitest
twine upload dist/* -r pypitest

Upload to real pypi
twine upload dist/* -r pypi -u -p

Last, this guy had a pretty good write up about packaging https://hynek.me/articles/sharing-your-labor-of-love-pypi-quick-and-dirty/. Not sure I am 100% clean yet, but with all of this, and copying from sqlalchemy's setup.py, I am well under way.

Thanks again.

@jpeyret

• https://python-packaging-user-guide.readthedocs.org/en/latest/distributing/ -> https://packaging.python.org/distributing/

This is an old gist, and I'm new to all of this. But isn't it odd to first commit your changes, then update version number in files and build the package, and then push the changes? Aren't you missing out on the version changes and the new build?

You can also use twine to securely upload to Pypi :twine upload dist/*

@BramVanroy no, because bumpversion creates another commit just for the version change. So in total you have one commit for the History changes, and one for the version bump.

Great list! Suggestion for an additional check: Run twine check dist/* after python setup.py sdist to run some additional checks (for example that the markdown/rst on pypi will render properly etc).