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

[Todd]

On Tue, Nov 29, 2016 at 4:13 AM, M.-A. Lemburg <mal at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161129/839ce805/attachment.html>