I am nearing completion of documenting the hooks API for the manual. And I
would like to comment on a design aspect.
(Let me start by saying this is in no way a criticism of the heroic efforts
of @laycec in building this API!)
The pre_safe_import_module hook API is the *only* place in the hook world
where we have exposed the existence of the ModuleGraph to the hook writer.
All other hook facilities are in terms of module name strings, or files in
the form of ('sourcepath', 'destname') tuples. But in
pre_safe_import_module hooks, the passed object offers both a parent graph
node, and the handle to the entire graph-as-built-to-date, and requires the
writer to use ModuleGraph class methods to do any work.
The existing hooks of this type are very limited. The group
hook-gi.repository.*.py all add a name to the graph using
api.module_graph.add_module( RuntimeModule( *name* ))
My point is, the graph call could be hidden in a method of the API object,
so the hook writer would only need to write, perhaps,
api.add_runtime_name( *name* )
The hook-six.moves.py hook does something different, it adds a series of
aliases, using
api.module_graph.alias_module(real_module_name, six_module_name)
Again this could have been done in a method of the API object so the hook
writer would not have to know about the graph as a graph.
Obviously a benefit to me would be, I would not have to explain the
ModuleGraph at any depth whatever. As it is, I have to say something about
ModuleGraph.
Since I don't want to even attempt to document the whole ModuleGraph API, I
will have to sketch what the three methods RuntimeModule(), add_module()
and alias_module() do, and say, if you think you need to know more, feel
free to read PyInstaller/lib/modulegraph/modulegraph...
Possibly it is envisioned that a future hook writer might need to full
access to ModuleGraph facilities (and full understanding of it). In that
case, fine, so be it.
However, if it is thought that the only two ModuleGraph features that a
hook will need are "add runtime name" and "create alias", then I would urge
that you make this API change NOW, while the only existing clients of the
API are the few in this release. Add two methods for those purposes to the
PreSafeImportModuleAPI class, change the existing 6 files to use them, and
do NOT expose the ModuleGraph to any hook writer.
Note if a need for some other ModuleGraph feature turns up in the future,
it could always be provided via another method of the
PreSafeImportModuleAPI class. The cost would be small and the benefit would
always be, that PyInstaller code stands between the hook writer and the
ModuleGraph, and can limit or censor that access -- where under the present
API it cannot.
Thanks for listening,
Dave Cortesi
--
You received this message because you are subscribed to the Google Groups
"PyInstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pyinstaller.
For more options, visit https://groups.google.com/d/optout.
