[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC qemu.qmp PATCH 17/24] Makefile: add build and publish targets
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC qemu.qmp PATCH 17/24] Makefile: add build and publish targets |
Date: |
Wed, 12 Jan 2022 10:07:07 +0000 |
User-agent: |
Mutt/2.1.3 (2021-09-10) |
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.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|