qemu-devel
[Top][All Lists]
Advanced

[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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]