From: Cleber Rosa <crosa@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>, "Fam Zheng" <fam@euphon.net>,
"Ben Widawsky" <ben@bwidawsk.net>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
qemu-block@nongnu.org,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel@nongnu.org,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Andrea Bolognani" <abologna@redhat.com>,
"Rohit Shinde" <rohit.shinde12194@gmail.com>,
"Willian Rampazzo" <wrampazz@redhat.com>,
"Max Reitz" <mreitz@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH v3 02/15] python: add qemu package installer
Date: Wed, 28 Oct 2020 15:46:32 -0400 [thread overview]
Message-ID: <20201028194632.GE2201333@localhost.localdomain> (raw)
In-Reply-To: <6498254a-46e0-a780-e7db-34275af734ae@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 6369 bytes --]
On Wed, Oct 28, 2020 at 01:02:52PM -0400, John Snow wrote:
> On 10/28/20 11:10 AM, Cleber Rosa wrote:
> > > +mirror <https://gitlab.com/jsnow/qemu/-/tree/python>`_, but
> > > +contributions must be sent to the list for inclusion.
> >
> > IMO it's not clear if this branch/mirror is your development work, a
> > staging area, etc.
> >
>
> Fair enough. jsnow/qemu/python is intended as a staging area for patches
> that have been vetted on-list.
>
> jsnow/qemu/master is a lazily-updated mirror. (I tend to update it every day
> as part of my development process, but there are days I don't write code.)
>
> jsnow/qemu/python-* is development work; review branches, etc.
>
> I'll try to rephrase this a bit. What I want to communicate:
>
> - This package exists as a subfolder of a larger project
> - I am responsible for maintaining this package, but not for the larger
> project
> - Please contact *me* for problems with this package
> - Contributions should go through qemu-devel (I will gently redirect
> contributors who may send pull requests to the qemu devel list.)
>
OK, sounds good. I'll look at the exact rewording on v+1.
> > > diff --git a/python/setup.cfg b/python/setup.cfg
> > > new file mode 100755
> > > index 0000000000..12b99a796e
> > > --- /dev/null
> > > +++ b/python/setup.cfg
> > > @@ -0,0 +1,18 @@
> > > +[metadata]
> > > +name = qemu
> > > +maintainer = QEMU Developer Team
> > > +maintainer_email = qemu-devel@nongnu.org
> > > +url = https://www.qemu.org/
> > > +download_url = https://www.qemu.org/download/
> > > +description = QEMU Python Build, Debug and SDK tooling.
> > > +long_description = file:PACKAGE.rst
> > > +long_description_content_type = text/x-rst
> > > +classifiers =
> > > + Development Status :: 3 - Alpha
> > > + License :: OSI Approved :: GNU General Public License v2 (GPLv2)
> > > + Natural Language :: English
> > > + Operating System :: OS Independent
> > > +
> >
>
> Also ... licensing question, do we need *L*GPLv2, or does Python not have a
> "linking exception" problem?
>
> I guess we can't really re-license these files anyway, so nevermind.
>
> (I immediately regret asking this.)
>
I'll just pretend you never did.
> > I know the sky is the limit, but I miss the Python version classifier,
> > at least:
> >
> > Programming Language :: Python :: 3 :: Only
> >
>
> Sure.
>
> Wait, why can you specify Python as a language? Is it possible to have
> non-Python packages on PyPI?
>
> *CONCERNED*
>
I guess it has to do with packages that can interact or serve other
languages. Or, that are (partially) written in another language?
> > And optionally those:
> >
> > Programming Language :: Python :: 3.6
> > Programming Language :: Python :: 3.7
> > Programming Language :: Python :: 3.8
> > Programming Language :: Python :: 3.9
> >
> > Although it may be a good idea to add them along test jobs on those
> > specific Python versions.
> >
>
> Are these worth adding? I've got python_requires >= 3.6 down below. From my
> test of a blank package upload to PyPI, it seems to display prominently:
>
> https://pypi.org/project/qemu/
>
> Is there a tangible benefit that you are aware of?
>
AFAICT, the classifiers are about letting people search for packages
that match a given criteria. It's all metadata, so the benefits are
not super tangible. I've used those to keep track / document the
Python versions that I know the project has been actively tested on,
and that's the reason of my comment about (CI) test jobs.
> > > +[options]
> > > +python_requires = >= 3.6
> > > +packages = find_namespace:
> > > diff --git a/python/setup.py b/python/setup.py
> > > new file mode 100755
> > > index 0000000000..e93d0075d1
> > > --- /dev/null
> > > +++ b/python/setup.py
> > > @@ -0,0 +1,23 @@
> > > +#!/usr/bin/env python3
> > > +"""
> > > +QEMU tooling installer script
> > > +Copyright (c) 2020 John Snow for Red Hat, Inc.
> > > +"""
> > > +
> > > +import setuptools
> > > +import pkg_resources
> > > +
> > > +
> > > +def main():
> > > + """
> > > + QEMU tooling installer
> > > + """
> > > +
> > > + # https://medium.com/@daveshawley/safely-using-setup-cfg-for-metadata-1babbe54c108
> > > + pkg_resources.require('setuptools>=39.2')
> >
> > Getting back to the "test jobs on those specific Python versions" I
> > was really anxious that environments with Python 3.6 will fail to
> > have such a "recent" setuptools version.
> >
>
> Reasonable doubt. However, this isn't *required* to use the library (the
> QEMU code can continue to just set PYTHONPATH or sys.path as necessary) and
> bypasses the installer entirely.
>
Right, but I had the impression that activating it in develop mode (at
least) was the intention down the line.
> That gives us some leeway apart from the usual version constraints; in order
> to independently use this library outside of the QEMU tree we may impose
> more modern setups -- as long as the minimum requirements for QEMU itself
> don't break.
>
OK.
> Having a modern setuptools in order to install seems like less of a problem
> barrier; and it seemed like a good idea to make it explicitly fail instead
> of silently doing something weird if it didn't see/understand setup.cfg.
>
Agreed.
> (And it seems like good practice to update pip in your venv, so I think
> we'll be OK except for the stodgiest of users, but sometimes you can't have
> new things on old systems without learning some new tricks!)
>
> > CentOS 8 has that specific version, while Ubuntu 18.04 has version
> > 39.0. Ubuntu 20.04 has a recent enough version though. Given that
> > all GitLab CI moved to 20.04, this should be safe.
> >
> > - Cleber.
> >
>
> FWIW, for the purposes of running the linters, I am using Fedora32 and the
> python36 package.
>
This is a minor suggestion: use CentOS 8 stock Python 3.6 packages,
and then Fedora 33 with also stock Python 3.9. Even though all
tools are pinned, it's still a good idea to test at least min/max
(if not all) Python versions.
- Cleber.
> > > +
> > > + setuptools.setup()
> > > +
> > > +
> > > +if __name__ == '__main__':
> > > + main()
> > > --
> > > 2.26.2
> > >
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-10-28 19:47 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-20 19:35 [PATCH v3 00/15] python: create installable package John Snow
2020-10-20 19:35 ` [PATCH v3 01/15] python: create qemu packages John Snow
2020-10-28 14:46 ` Cleber Rosa
2020-10-28 15:21 ` John Snow
2020-10-28 16:39 ` Cleber Rosa
2020-10-28 19:54 ` John Snow
2020-10-20 19:35 ` [PATCH v3 02/15] python: add qemu package installer John Snow
2020-10-28 15:10 ` Cleber Rosa
2020-10-28 17:02 ` John Snow
2020-10-28 19:46 ` Cleber Rosa [this message]
2020-10-28 20:25 ` John Snow
2020-10-28 19:49 ` Cleber Rosa
2020-10-28 20:25 ` John Snow
2020-10-20 19:35 ` [PATCH v3 03/15] python: add VERSION file John Snow
2020-10-28 19:51 ` Cleber Rosa
2020-10-28 20:00 ` John Snow
2020-10-20 19:35 ` [PATCH v3 04/15] python: add directory structure README.rst files John Snow
2020-10-28 22:05 ` Cleber Rosa
2020-10-28 23:53 ` John Snow
2020-10-20 19:35 ` [PATCH v3 05/15] python: Add pipenv support John Snow
2020-10-28 22:22 ` Cleber Rosa
2020-10-20 19:35 ` [PATCH v3 06/15] python: add pylint import exceptions John Snow
2020-10-28 22:24 ` Cleber Rosa
2020-10-28 23:55 ` John Snow
2020-10-20 19:35 ` [PATCH v3 07/15] python: move pylintrc into setup.cfg John Snow
2020-10-28 22:29 ` Cleber Rosa
2020-10-20 19:35 ` [PATCH v3 08/15] python: add pylint to pipenv John Snow
2020-10-28 22:38 ` Cleber Rosa
2020-10-29 0:06 ` John Snow
2020-10-20 19:35 ` [PATCH v3 09/15] python: move flake8 config to setup.cfg John Snow
2020-10-28 22:40 ` Cleber Rosa
2020-10-20 19:35 ` [PATCH v3 10/15] python: Add flake8 to pipenv John Snow
2020-10-28 22:41 ` Cleber Rosa
2020-10-20 19:35 ` [PATCH v3 11/15] python: move mypy.ini into setup.cfg John Snow
2020-10-28 22:42 ` Cleber Rosa
2020-10-20 19:35 ` [PATCH v3 12/15] python: add mypy to pipenv John Snow
2020-10-28 22:43 ` Cleber Rosa
2020-10-20 19:35 ` [PATCH v3 13/15] python: move .isort.cfg into setup.cfg John Snow
2020-10-28 22:44 ` Cleber Rosa
2020-10-20 19:35 ` [PATCH v3 14/15] python/qemu: add isort to pipenv John Snow
2020-10-28 22:46 ` Cleber Rosa
2020-10-29 0:07 ` John Snow
2020-10-20 19:35 ` [PATCH v3 15/15] python/qemu: add qemu package itself " John Snow
2020-10-28 22:59 ` Cleber Rosa
2020-10-29 0:10 ` John Snow
2020-10-27 22:08 ` [PATCH v3 00/15] python: create installable package John Snow
2020-10-28 9:37 ` Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201028194632.GE2201333@localhost.localdomain \
--to=crosa@redhat.com \
--cc=abologna@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=ben@bwidawsk.net \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=fam@euphon.net \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rohit.shinde12194@gmail.com \
--cc=wainersm@redhat.com \
--cc=wrampazz@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.