Re: [RFC qemu.qmp PATCH 17/24] Makefile: add build and publish targets

[John Snow]

On Wed, Jan 12, 2022 at 5:07 AM Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Tue, Jan 11, 2022 at 02:48:55PM -0500, John Snow wrote:
> > On Fri, Dec 17, 2021 at 8:46 AM Daniel P. Berrangé <berrange@redhat.com>
> > wrote:
> >
> > > 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.
>
> FWIW, don't consider this original comment of mine to be a technical
> blocker, rather it is more of a conceptual observation.  If you don't
> think it matters, I won't mind.
>

OK, thanks -- just didn't want to give the impression I was just
simply ignoring it, since I appreciate the look-over.

--js