On 29 November 2016 at 20:54, Tomas Orsava <torsava@redhat.com> wrote:
With a metapath hook, .missing.py files are probably overkill, and the hook can just look at one file (or a static compiled-in list) of ModuleNotFound/ImportError messages for all missing modules, as M.-A. Lemburg and others are suggesting. We'll just need to think about coordinating how the list is generated/updated: the current PEP implicitly allows other parties, besides Python and the distributors, to step in cleanly if they need to—needing to update a single list could lead to messy hacks.
What if, rather than using an explicitly file-based solution, this was instead defined as a new protocol module, where the new metapath hook imported a "__missing__" module and called a particular function in it (e.g. "__missing__.module_not_found(modname)")? The default missing module implementation hook would just handle CPython's optional modules, but redistributors could patch it to use a mechanism that made sense for them. For example, if we ever get to the point where the Fedora RPM database includes "Provides: pythonXYimport(module.of.interest)" data in addition to "Provides: pythonXYdist(pypi-package-name)" , the right system package to import could be reported for any module, not just standard library ones that have been split out (with the trade-off being that any such checks would make optional imports a bit slower to fail, but that could be mitigated in various ways). Specific applications could also implement their own missing module handling by providing a __missing__.py file alongside their __main__.py, and relying on directory and/or zipfile execution, or else by monkeypatching the __missing__ module at runtime. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia