[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PULL 0/5] Python patches
Re: [PULL 0/5] Python patches
Wed, 17 Nov 2021 22:12:56 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0
17.11.2021 22:07, John Snow wrote:
On Wed, Nov 17, 2021 at 1:20 PM Vladimir Sementsov-Ogievskiy <email@example.com
17.11.2021 20:56, John Snow wrote:
> On Wed, Nov 17, 2021 at 4:42 AM Gerd Hoffmann <firstname.lastname@example.org
<mailto:email@example.com> <mailto:firstname.lastname@example.org <mailto:email@example.com>>>
> > https://gitlab.com/jsnow/qemu.git <https://gitlab.com/jsnow/qemu.git>
> What is the status of the plan to upload this to pypi eventually?
> Thanks for asking!
> The honest answer is "I'm not exactly sure", but there are a few things
to work out still. Let me use this as an opportunity to try and give you an honest answer.
> We've got four packages right now: qmp, aqmp, machine and utils.
> - I don't intend to *ever* upload utils, I created that one specifically as an
in-tree package for "low quality" code that we just need as glue.
> - aqmp is brand new. It was moved as the default provider for the QMP
protocol in the tree (being used by machine.py) only two weeks ago. I am using
this current RC testing phase to find any problems with it.
> - qmp is something I want to deprecate, I don't intend to upload it to
PyPI. I intend to rename aqmp -> qmp and have just the one qmp package. I can't do
this until next release, and only after we are confident and happy that aqmp is
> - machine has a few problems with it. I am reluctant to upload it in its
current form. I am actively developing a new version of it that uses the new Async
QMP module. However, this might take a bit of time, I fear.
> So, I think I have this timeline for myself:
> - Fix bugs in AQMP package revealed during RC testing
> - Introduce sync wrapper for AQMP that resembles the native AQMP interface more
than it resembles the "legacy QMP" interface.
> - Remove all QEMU source tree uses of qemu.qmp and qemu.aqmp.legacy.
> - Delete qemu.qmp and rename qemu.aqmp to qemu.qmp.
> - Split python/qemu/qmp out into its own repository and begin uploading
it to PyPI, as a test. (Do not delete python/qemu/qmp yet at this phase.)
> - Transition any users of the Python packages in the QEMU source tree to
installing the QMP dependency from PyPI instead of grabbing it from the tree.
> - Delete python/qemu/qmp from the QEMU source tree at this moment; "re-fork" the
package if necessary to collect any commits since the "test split" procedure.
That all sounds great!
> Some questions to work out:
> - What tools should be uploaded with qemu.qmp? a version of qmp-shell is high on
the list for me. qom, qom-set, qom-get, qom-list, qom-tree, qom-fuse etc I am suspecting
might be better left behind in qemu.utils instead, though. I am not sure I want to support
those more broadly. They weren't designed for "external consumption".
> - qemu-ga-client should be moved over into utils, or possibly even
deleted -- it hasn't seen a lot of love and I doubt there are any users. I don't
have the bandwidth to refurbish it for no users. Maybe if there's a demand in the
> ... This might be being overcautious, though. Perhaps I can upload a version of
"qemu.aqmp" even this week just as a demonstration of how it would work.
Why do we need wait for next release for renaming aqmp -> qmp? Or what next
release do you mean? I think you can rename it as soon as 6.3 development phase is
I might be confused in my thinking because there's a ton of little tasks to do,
and I won't pretend I have thought extremely carefully about the precise order
in which they *have* to be done, only the order in which that it occurs to me
to do them. :)
I suppose I could do something like rename "qmp" to "legacy_qmp" in the tree as an
intermediate step and accomplish the "aqmp -> qmp" rename sooner, but there's a lot of churn
inherent to that. Since there's a lot of churn inherent to moving users off of the old interface anyway, I
figured I'd just tackle it all at once... which I can't do until the tree re-opens again.
I can certainly work on it in the meantime, though.
I'm not sure that's a good idea to upload qemu.aqmp to public and than
rename it to qemu.qmp.. Maybe, you can upload it now as qemu.qmp? So, first,
create a separate repo with aqmp (already renamed to qmp), upload it to PyPI
(as qmp) - this all as a first step. And then gradually move Qemu to use this
new repo instead its own qmp/aqmp.
I'm afraid of doing this because I don't want to pollute the 'qemu.qmp' space with two
packages that contain radically different things in it. It feels safer to fully switch
over the QEMU source tree first, and THEN upload to PyPI. If I go out of order there, I
worry that we will run into circumstances where various scripts/tools will use "the
wrong qemu.qmp", and it will be frustrating for people without a lot of Python
packaging experience to diagnose on their own.
The safest thing is just to wait for me to do all the cleanup churn I laid out above, but
if I were to demo a "preview", doing it under the 'qemu.aqmp' name seems like
the safest bet because I don't plan to use that name long-term.
OK, that's right. I just imagined a "fast path", but it's not safe, you are
- [PULL 1/5] python/aqmp: Fix disconnect during capabilities negotiation, (continued)
- [PULL 1/5] python/aqmp: Fix disconnect during capabilities negotiation, John Snow, 2021/11/16
- [PULL 2/5] python/aqmp: fix ConnectError string method, John Snow, 2021/11/16
- [PULL 3/5] scripts/device-crash-test: simplify Exception handling, John Snow, 2021/11/16
- [PULL 4/5] scripts/device-crash-test: don't emit AQMP connection errors to stdout, John Snow, 2021/11/16
- [PULL 5/5] scripts/device-crash-test: hide tracebacks for QMP connect errors, John Snow, 2021/11/16
- Re: [PULL 0/5] Python patches, Richard Henderson, 2021/11/17
- Re: [PULL 0/5] Python patches, Gerd Hoffmann, 2021/11/17
- Re: [PULL 0/5] Python patches, Gerd Hoffmann, 2021/11/18
- Re: [PULL 0/5] Python patches, John Snow, 2021/11/18