+1, I would like waiverdb on pypi and upload new release there as part of the script too :).

Yes good idea. Should be just something like

rm -f dist/*.tar.gz
python setup.py sdist
twine upload dist/*.tar.gz

We will just need to register it on PyPI first.

Hm, I'm using just python setup.py sdist upload for MBS. Anyway, with pypi upload, I could use exactly the same script for MBS and Freshmaker :).

Hmm okay, not totally sure what the difference is between using twine and setup.py sdist upload...

Also I just realised this script doesn't git push the tag either. In Beaker we use that as a last sanity check to make sure the script has done the right thing before publishing the tag permanently.

But if the script is going to upload to PyPI then it's already too late to fix anything :-) so in that case it should really push the tag too.

I see, it looks sane to do it without sdist upload then :).

Yeah I think let's leave it as is for now, without git push or uploading to PyPI, and we can expand it later.

:+1: from me, apart from one observation:

This is keeping the same tagging convention as we use in Beaker (which came out of tito which came out of Satellite which was influenced by CVS conventions originally I guess): waiverdb-0.1 with the project name prefixed on the front. Whereas all the kids on Github these days tend to just tag with a raw version number, sometimes prefixed with a v, as in 0.1 or v0.1. ResultsDB also uses this latter convention.

Personally I like the full tag waiverdb-0.1 but if anyone objects, now would be the time to speak up before we make our first tag. :-)

No objections here.

Cool, no objections, I'll merge this.