Skip to content

Instantly share code, notes, and snippets.

@audreyfeldroy
Last active February 23, 2023 15:03
Show Gist options
  • Save audreyfeldroy/5990987 to your computer and use it in GitHub Desktop.
Save audreyfeldroy/5990987 to your computer and use it in GitHub Desktop.
My PyPI Release Checklist
  • 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.
@michaeljoseph
Copy link

@audreyr, I've tried to automate this awesome checklist with changes.
Thanks for the inspiration 😄.
Also for cookiecutter 😍

@mgedmin
Copy link

mgedmin commented Apr 27, 2014

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!

@chhantyal
Copy link

You might want to upload to PyPi as wheel format.

@chrisvoncsefalvay
Copy link

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

@audreyfeldroy
Copy link
Author

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

@audreyfeldroy
Copy link
Author

The simplified checklist is now in.

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

@billyshambrook
Copy link

Awesome, straight to the point, checklist.

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

@jpeyret
Copy link

jpeyret commented Feb 23, 2016

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.

@BramVanroy
Copy link

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?

@rutgerhofste
Copy link

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

@zertrin
Copy link

zertrin commented May 14, 2018

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

@klieret
Copy link

klieret commented May 3, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment