qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>, "Fam Zheng" <fam@euphon.net>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	qemu-block@nongnu.org,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Max Reitz" <mreitz@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH 0/7] python: create installable package
Date: Mon, 8 Jun 2020 10:14:44 -0400	[thread overview]
Message-ID: <55ea34e7-c0b3-73ff-4e2d-7c127263af02@redhat.com> (raw)
In-Reply-To: <8f64d361-d167-f539-8c8e-b432b037be36@virtuozzo.com>



On 6/6/20 1:53 AM, Vladimir Sementsov-Ogievskiy wrote:
> For patches 05-07:
> 
> Reviewing such patch is a strange thing: Pipfile changes are obvious
> enough, just select some version (I can't be sure about correct version
> choice, just believe in your commit messages). But what for
> Pipfile.lock? I can state that it's about package set selecting,
> Pipfile.lock looks like what it should be, but I have idea about all
> these packages, their versions and hashes (and even, does it correspond
> really to Pipfile or not) :)
> 
> Ha, what I can check, is: does pipenv create almost same Pipfile.lock in
> my environment (with 3.7.5 python)
> OK, I've tried (pipenv lock --dev --python /usr/bin/python3), and yes,
> result is almost the same. For mypy and importlib-metadata packages I
> have newer version and different hashes (of course). Other packages are
> the same. Set of packages is the same.
> 
> Hmm, but in may generated Pipfile.lock there no "markers". They are
> about python version and looks like "markers": "python_version >=
> '3.5'".. Does pipenv follow them? Then why they are not generated for
> me, did you use some additional command/option to create them?
> Anyway, they don't look dangerous, so for last three patches:
> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> 

Yes, from a blank repository you can do "pipenv install mypy>=0.730" --
it uses the same package specification syntax that pip uses.

(Or, you can edit the Pipfile manually, which is what I actually did.
The benefit of doing so is primarily about documenting our minimum
version requirements. I suppose in truth, those minimums should go into
setup.py too, actually.)

Thanks for taking a look!

--js

> 03.06.2020 03:15, John Snow wrote:
>> Based-on: 20200602214528.12107-1-jsnow@redhat.com
>>
>> This series factors the python/qemu directory as an installable
>> module. As a developer, you can install this to your virtual environment
>> and then always have access to the classes contained within without
>> needing to wrangle python import path problems.
>>
>> When developing, you could go to qemu/python/ and invoke `pipenv shell`
>> to activate a virtual environment within which you could type `pip
>> install -e .` to install a special development version of this package
>> to your virtual environment. This package will always reflect the most
>> recent version of the source files in the tree.
>>
>> When not developing, you could install a version of this package to your
>> environment outright to gain access to the QMP and QEMUMachine classes
>> for lightweight scripting and testing.
>>
>> This package is formatted in such a way that it COULD be uploaded to
>> https://pypi.org/project/qemu and installed independently of qemu.git
>> with `pip install qemu`, but of course that button remains unpushed.
>>
>> There are a few major questions to answer first:
>>
>> - What versioning scheme should we use? See patch 2.
>>
>> - Should we use a namespace package or not?
>>    - Namespaced: 'qemu.machine', 'qemu.monitor' etc may be separately
>>      versioned, packaged and distributed packages. Third party authors
>>      may register 'qemu.xxx' to create plugins within the namespace as
>>      they see fit.
>>
>>    - Non-namespaced: 'qemu' is one giant glob package, packaged and
>>      versioned in unison. We control this package exclusively.
>>
>> - How do we eliminate sys.path hacks from the rest of the QEMU tree?
>>    (Background: sys.path hacks generally impede the function of static
>>    code quality analysis tools like mypy and pylint.)
>>
>>    - Simplest: parent scripts (or developer) needs to set PYTHONPATH.
>>
>>    - Harder: Python scripts should all be written to assume package form,
>>      all tests and CI that use Python should execute within a VENV.
>>
>>    In either case, we lose the ability (for many scripts) to "just run" a
>>    script out of the source tree if it depends on other QEMU Python
>>    files. This is annoying, but as the complexity of the Python lib
>>    grows, it is unavoidable.
>>
>>    In the VENV case, we at least establish a simple paradigm: the scripts
>>    should work in their "installed" forms; and the rest of the build and
>>    test infrastructure should use this VENV to automatically handle
>>    dependencies and path requirements. This should allow us to move many
>>    of our existing python scripts with "hidden" dependencies into a
>>    proper python module hierarchy and test for regressions with mypy,
>>    flake8, pylint, etc.
>>
>>    (We could even establish e.g. Sphinx versions as a dependency for our
>>    build kit here and make sure it's installed to the VENV.)
>>
>>    Pros: Almost all scripts can be moved under python/qemu/* and checked
>>    with CQA tools. imports are written the same no matter where you are
>>    (Use the fully qualified names, e.g. qemu.core.qmp.QMPMessage).
>>    Regressions in scripts are caught *much* faster.
>>
>>    Downsides: Kind of annoying; most scripts now require you to install a
>>    devkit forwarder (pip3 install --user .) or be inside of an activated
>>    venv. Not too bad if you know python at all, but it's certainly less
>>    plug-n-play.
>>
>> - What's our backwards compatibility policy if we start shipping this?
>>
>>    Proposed: Attempt to maintain API compatibility (after stabilizing the
>>    library). Incompatible changes should probably cause a semver bump.
>>
>>    Each published release makes no attempt to support any version of QEMU
>>    other than the one it was released against. We publish this on the tin
>>    in big red letters.
>>
>> TESTING THIS PACKAGE OUT:
>>
>> 1. You can install to your local user's environment normally by
>> navigating to qemu/python/ and typing "pip3 install --user ."
>>
>> 2. If you are in a VENV, use "pip install ."
>>
>> 3. To install in development mode (Where the installed package always
>> reflects the most recent version of the files automatically), use "pip3
>> install -e ." or "pip install -e ." as appropriate (See above)
>>
>> John Snow (7):
>>    python/qemu: create qemu.lib module
>>    python/qemu: formalize as package
>>    python/qemu: add README.rst
>>    python/qemu: Add pipenv support
>>    python/qemu: add pylint to pipenv
>>    python/qemu: Add flake8 to pipenv
>>    python/qemu: add mypy to pipenv
>>
>>   python/README.rst                         |   6 +
>>   python/qemu/README.rst                    |   8 +
>>   python/Pipfile                            |  14 ++
>>   python/Pipfile.lock                       | 195 ++++++++++++++++++++++
>>   python/qemu/__init__.py                   |  11 --
>>   python/qemu/{ => core}/.flake8            |   0
>>   python/qemu/core/__init__.py              |  57 +++++++
>>   python/qemu/{ => core}/accel.py           |   0
>>   python/qemu/{ => core}/machine.py         |   0
>>   python/qemu/{ => core}/pylintrc           |   0
>>   python/qemu/{ => core}/qmp.py             |   0
>>   python/qemu/{ => core}/qtest.py           |   0
>>   python/setup.py                           |  50 ++++++
>>   scripts/device-crash-test                 |   2 +-
>>   scripts/qmp/qemu-ga-client                |   2 +-
>>   scripts/qmp/qmp                           |   2 +-
>>   scripts/qmp/qmp-shell                     |   2 +-
>>   scripts/qmp/qom-fuse                      |   2 +-
>>   scripts/qmp/qom-get                       |   2 +-
>>   scripts/qmp/qom-list                      |   2 +-
>>   scripts/qmp/qom-set                       |   2 +-
>>   scripts/qmp/qom-tree                      |   2 +-
>>   scripts/render_block_graph.py             |   6 +-
>>   scripts/simplebench/bench_block_job.py    |   4 +-
>>   tests/acceptance/avocado_qemu/__init__.py |   2 +-
>>   tests/acceptance/boot_linux.py            |   3 +-
>>   tests/acceptance/virtio_check_params.py   |   2 +-
>>   tests/acceptance/virtio_version.py        |   2 +-
>>   tests/migration/guestperf/engine.py       |   2 +-
>>   tests/qemu-iotests/235                    |   2 +-
>>   tests/qemu-iotests/297                    |   2 +-
>>   tests/qemu-iotests/iotests.py             |   4 +-
>>   tests/vm/basevm.py                        |   6 +-
>>   33 files changed, 355 insertions(+), 39 deletions(-)
>>   create mode 100644 python/README.rst
>>   create mode 100644 python/qemu/README.rst
>>   create mode 100644 python/Pipfile
>>   create mode 100644 python/Pipfile.lock
>>   delete mode 100644 python/qemu/__init__.py
>>   rename python/qemu/{ => core}/.flake8 (100%)
>>   create mode 100644 python/qemu/core/__init__.py
>>   rename python/qemu/{ => core}/accel.py (100%)
>>   rename python/qemu/{ => core}/machine.py (100%)
>>   rename python/qemu/{ => core}/pylintrc (100%)
>>   rename python/qemu/{ => core}/qmp.py (100%)
>>   rename python/qemu/{ => core}/qtest.py (100%)
>>   create mode 100755 python/setup.py
>>
> 
> 

-- 
—js



  reply	other threads:[~2020-06-08 14:16 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03  0:15 [PATCH 0/7] python: create installable package John Snow
2020-06-03  0:15 ` [PATCH 1/7] python/qemu: create qemu.lib module John Snow
2020-06-05 12:33   ` Vladimir Sementsov-Ogievskiy
2020-06-03  0:15 ` [PATCH 2/7] python/qemu: formalize as package John Snow
2020-06-05 14:40   ` Vladimir Sementsov-Ogievskiy
2020-06-05 15:42     ` John Snow
2020-06-05 19:23     ` John Snow
2020-06-03  0:15 ` [PATCH 3/7] python/qemu: add README.rst John Snow
2020-06-05 14:56   ` Vladimir Sementsov-Ogievskiy
2020-06-05 16:18     ` John Snow
2020-06-03  0:15 ` [PATCH 4/7] python/qemu: Add pipenv support John Snow
2020-06-05 15:37   ` Vladimir Sementsov-Ogievskiy
2020-06-05 15:54     ` John Snow
2020-06-05 16:21   ` Vladimir Sementsov-Ogievskiy
2020-06-05 17:11     ` John Snow
2020-06-06  5:31       ` Vladimir Sementsov-Ogievskiy
2020-06-03  0:15 ` [PATCH 5/7] python/qemu: add pylint to pipenv John Snow
2020-06-03  0:15 ` [PATCH 6/7] python/qemu: Add flake8 " John Snow
2020-06-03  0:15 ` [PATCH 7/7] python/qemu: add mypy " John Snow
2020-06-06  5:53 ` [PATCH 0/7] python: create installable package Vladimir Sementsov-Ogievskiy
2020-06-08 14:14   ` John Snow [this message]
2020-06-17 19:52 ` Cleber Rosa
2020-06-17 20:27   ` John Snow
2020-06-18  9:23     ` Kevin Wolf
2020-06-19 15:04       ` John Snow
2020-06-19 16:44         ` Kevin Wolf
2020-06-19 17:14           ` John Snow
2020-06-19 15:09       ` Philippe Mathieu-Daudé
2020-06-19 15:15     ` Philippe Mathieu-Daudé
2020-06-19 16:10       ` John Snow

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=55ea34e7-c0b3-73ff-4e2d-7c127263af02@redhat.com \
    --to=jsnow@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=crosa@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).