On 7 December 2016 at 18:33, M.-A. Lemburg <mal@egenix.com> wrote:
I know that you started this thread focusing on the stdlib, but for the purpose of distributors, the scope goes far beyond just the stdlib.
Basically any Python module or package which the distribution can provide should be usable as basis for a nice error message pointing to the package to install.
The PEP draft covered two questions: - experienced redistributors breaking the standard library up into pieces - optional modules for folks building their own Python (even if they're new to that)
Now, it's the distribution which knows which modules/packages are available, so we don't need a list of stdlib modules in Python to help with this.
Right, that's the case that we realised can be covered entirely by the suggestion "patch site.py to install a different default sys.excepthook()"
A list of stdlib modules may still be useful, but it comes with it's own set of problems, which should be irrelevant for this use case: some stdlib modules are optional and only available if the system provides (and Python can find) certain libs (or header files during compilation).
While upstream changes turned out not to be necessary for the "distributor breaking up the standard library" use case, they may still prove worthwhile in making import errors more informative in the case of "I just built my own Python from upstream sources and didn't notice (or didn't read) the build message indicating that some modules weren't built". Given the precedent of the sysconfig metadata generation, providing some form of machine-readable build-time-generated module manifest should be pretty feasible if someone was motivated to implement it, and we already have the logic to track which optional modules weren't built in order to generate the message at the end of the build process. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia