On Thu, Dec 16, 2021 at 06:35:23PM -0500, John Snow wrote:
> On Thu, Dec 16, 2021 at 5:48 AM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
>
> > On Wed, Dec 15, 2021 at 04:06:27PM -0500, John Snow wrote:
> > > Signed-off-by: John Snow <jsnow@redhat.com>
> > > ---
> > > Makefile | 32 ++++++++++++++++++++++++++++++++
> > > 1 file changed, 32 insertions(+)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 97d737a..81bfca8 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -110,3 +110,35 @@ distclean: clean
> > > rm -f .coverage .coverage.*
> > > rm -rf htmlcov/
> > > rm -rf test-results/
> > > +
> > > +.PHONY: pristine
> > > +pristine:
> > > + @git diff-files --quiet --ignore-submodules -- || \
> > > + (echo "You have unstaged changes."; exit 1)
> > > + @git diff-index --cached --quiet HEAD --ignore-submodules -- || \
> > > + (echo "Your index contains uncommitted changes."; exit 1)
> > > + @[ -z "$(shell git ls-files -o)" ] || \
> > > + (echo "You have untracked files: $(shell git ls-files
> > -o)"; exit 1)
> > > +
> > > +dist: setup.cfg setup.py Makefile README.rst
> > > + python3 -m build
> > > + @touch dist
> > > +
> > > +.PHONY: pre-publish
> > > +pre-publish: pristine dist
> > > + @git describe --exact-match 2>/dev/null || \
> > > + (echo -e "\033[0;31mThere is no annotated tag for this
> > commit.\033[0m"; exit 1)
> > > + python3 -m twine check --strict dist/*
> > > + git push -v --atomic --follow-tags --dry-run
> > > +
> > > +.PHONY: publish
> > > +publish: pre-publish
> > > + # Set the username via TWINE_USERNAME.
> > > + # Set the password via TWINE_PASSWORD.
> > > + # Set the pkg repository via TWINE_REPOSITORY.
> > > + python3 -m twine upload --verbose dist/*
> > > + git push -v --atomic --follow-tags
> > > +
> > > +.PHONY: publish-test
> > > +publish-test: pre-publish
> > > + python3 -m twine upload --verbose -r testpypi dist/*
> >
> > It doesn't feel very pythonic to have a makefile in the project.
> >
> > If we want some helpers for publishing releases, I would have
> > expected to see a python script eg scripts/publish.py
> >
> >
> Eh, Python folks use Makefiles too. I've been using these little Makefile
> targets for hobby things for a while and I had them laying around and ready
> to go. I have no strong need to "upgrade" to python scripts for these right
> now, unless there's some extra features you want to see.
Using make means you have to worry about portability across different
impls of make and different impls of shell. Using python means your
python project is portable to anywhere that python runs.
I still like the idea of using a Makefile as a "canonical menu of things you can do in this directory", but there's probably room for interactive error checking and so on with the TWINE_USERNAME / TWINE_PASSWORD / TWINE_REPOSITORY environment variables in a python script. I'll look into it as a follow-up, if that's fine. (I'm worried it's a lot of polish and effort on a maintainers-only interface that only I will likely use for at least the next year or two.)
Ultimately, what's likely to happen here is that I will generate some oauth tokens with publish permissions and a hypothetical user would set e.g. TWINE_USERNAME to "__token__", and the password would be "pypi-tokengoeshere". Using the "keyring" python package, we could attempt to fetch stored values from a session keyring, falling back to an interactive prompt if they're unset.
--js