Re: [PATCH] qapi: Fix code generation with Python 3.5

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 1/17/20 8:41 PM, John Snow wrote:
> On 1/17/20 2:07 AM, Markus Armbruster wrote:
>> John Snow <jsnow@redhat.com> writes:
>>
>>> On 1/16/20 3:25 PM, Markus Armbruster wrote:
>>>> Recent commit 3e7fb5811b "qapi: Fix code generation for empty modules"
>>>> modules" switched QAPISchema.visit() from
>>>>
>>>>      for entity in self._entity_list:
>>>>
>>>> effectively to
>>>>
>>>>      for mod in self._module_dict.values():
>>>>          for entity in mod._entity_list:
>>>>
>>>> Visits in the same order as long as .values() is in insertion order.
>>>> That's the case only for Python 3.6 and later.  Before, it's in some
>>>> arbitrary order, which results in broken generated code.
>>>>
>>>> Fix by making self._module_dict an OrderedDict rather than a dict.
>>>>
>>>> Fixes: 3e7fb5811baab213dcc7149c3aa69442d683c26c
>>>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>>>> ---
>>>>   scripts/qapi/schema.py | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py
>>>> index 0bfc5256fb..5100110fa2 100644
>>>> --- a/scripts/qapi/schema.py
>>>> +++ b/scripts/qapi/schema.py
>>>> @@ -795,7 +795,7 @@ class QAPISchema(object):
>>>>           self.docs = parser.docs
>>>>           self._entity_list = []
>>>>           self._entity_dict = {}
>>>> -        self._module_dict = {}
>>>> +        self._module_dict = OrderedDict()
>>>>           self._schema_dir = os.path.dirname(fname)
>>>>           self._make_module(None) # built-ins
>>>>           self._make_module(fname)
>>>>
>>>
>>> This problem has bitten me *many* times. I'm wondering if there's a
>>> prescription that isn't just "Wait until we can stipulate 3.6+".
>>
>> No clue.
>>
>> 3.5 EOL is scheduled for 2020-09-13.
>> https://devguide.python.org/#status-of-python-branches
>>
>> We support 3.5 because we support Debian 9.
>>
>> We'd normally drop support for Debian 9 two years after Debian 10,
>> i.e. July 2021.  Assuming Debian supports it that far.  Whether they can
>> truly support Python 3.5 after uptstream EOL seems doubtful.
>>
> 
> We should decide whether we consider Debian LTS to be adequately
> supported, yes-or-no.
> 
> We should use a rule of "two years after successor, or End-of-Support,
> whichever comes first."
> 
> For Debian, is end of support three years after it comes out, or is it
> when the LTS is EOL?
> 
> In this specific case, do we trust that Debian 9 LTS will continue to
> patch Python3.5 all the way up until July 2021?

This broke 29 of the 32 Travis jobs we have:

https://travis-ci.org/qemu/qemu/builds/637999366

Since we started to use Travis CI, it catched quite some bugs...

I think it is important to add in the equation we also depend of our CIs.