On Tue, Nov 29, 2016 at 4:13 AM, M.-A. Lemburg <mal@egenix.com> wrote:
On 29.11.2016 00:50, Brett Cannon wrote:
> Seventh, these *.missing.py files if they are directly executed are totally
> going to be abused like *.pth files, I can just feel it in my bones. We
> need to be okay with this if we accept this PEP as-is.

Since the purpose of the PEP was to allow distributors to guide
users through the installation process of extra packages in order
to get access to parts of the stdlib which are not installed,
I think the PEP is overly broad in concept to address this one
use case.

Just as with .pth files, the possibility to hook arbitrary code
execution into the module search path will get abused for
all kinds of weird things, esp. if the whole sys.path is
scanned for the .missing.py module and not only the part
where the stdlib lives (as was suggested in the thread).

So why not limit the PEP to just the intended use case ?


I think a better question is why should we artificially limit the PEP?  These is something that could be useful outside of the stdlib.  At least for Linux packages it is common to split out optional components of a python package into separate linux packages to limit the size and dependencies of the main package.  This could help a lot in that situation.
 
I.e. define a static list of modules which do make up the Python
stdlib and then have the importer turn a ModuleNotFoundError error
into a nice distribution specific error message, if and only
if the imported module is from the set of stdlib modules.

This is hard to do in a general sense.  The point is to be able to tell the user what package they should install to get that functionality, but there is no general rule as to what the package should be named, and platform-specific modules would not be installable at all.  So every module would need its own error message defined. 
 
 
Thinking about this some more...

We don't even need a list of stdlib modules. Simply define
a general purpose import error formatting function, e.g.
sys.formatimporterror(), pass in the name of the module and
let it determine the error message based on the available
information.

A distributor could then provide a custom function that
knows about the installed Python packages and then guides
the user to install any missing ones.



 This is getting pretty complicated compared to simply defining a one-line text file containing the error message with the module name somewhere in the file name, as others have proposed.