Re: [PATCH 11/12] qapi/schema: Name the builtin module "" instead of None

[John Snow]

On 12/16/20 5:42 AM, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
>
> > Instead of using None as the built-in module filename, use an empty
> > string instead.
>
> PATCH 05's changes the module name of the special system module for
> built-in stuff from None to './builtin'.  The other system modules are
> named like './FOO': './init' and './emit' currently.
>
> This one changes the module *filename* from None to "", and not just for
> the builtin module, but for *all* system modules.  Your commit message
> claims only "the built-in module", which is not true as far as I can
> tell.

Is this true? ... "./init" and "./emit" are defined only in the 
generators, outside of the schema entirely. They don't even have 
"QAPISchemaModule" objects associated with them.

I changed:

        self._make_module(None)  # built-ins 


to

        self._make_module(QAPISourceInfo.builtin().fname)  # built-ins 



that should be precisely only "the" built-in module, shouldn't it? the 
other "system" modules don't even pass through _make_module.

> Should we use the opportunity to make the filename match the module
> name?

If that's something you want to have happen, it can be done, yes.

I had a draft that did it that way initially; I was afraid I was mixing 
up two distinct things: the module fname (schema.py's concept of 
modules) and module name (gen.py's concept of modules). This version of 
my patch kept the two more distinct like they are currently.

We can change "the" built-in module to have an fname of "./builtin" 
which works just fine; gen.py just has to change to not add "./" to 
modules already declared with the leading slash.

Up for debate is if you want the system modules declared in the code 
generators to have to declare 'emit' or './emit'; I left them alone and 
allowed them to say 'event'.

Downside: the ./ prefix takes on special meaning in both gen.py and 
schema.py. the module organization feels decentralized and fragile.

> >                  This allows us to clarify the type of various interfaces
> > dealing with module names as always taking a string, which saves us from
> > having to use Optional[str] everywhere.
> >
> > Signed-off-by: John Snow <jsnow@redhat.com>