[Python-ideas] PEP: Distributing a Subset of the Standard Library

[Nick Coghlan]

On 29 November 2016 at 20:54, Tomas Orsava <torsava at 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 at gmail.com   |   Brisbane, Australia