On Jun 23, 2018, at 18:56, Nick Coghlan <report@bugs.python.org> wrote:
> 
> My request (wearing my "BDFL-delegate for packaging interoperability standards" hat) is that proponents of the change resist the temptation to view the problem that way :)
> 
> Path files are used extensively across the Python packaging ecosystem to implement additional environment management features beyond those provided natively by interpreter implementations, and while we've added native equivalents for some of them (namespace packages, virtual environments), we're far from having added support for all of them (dynamic package version selection, virtual environment chaining, editable package installs that still publish correct PEP 376 package metadata, etc).

Still, I firmly believe they’re a wart being abused for purposes they weren’t really intended for.  It’s a trick of implementation that lines beginning with `import` are exec’d.  That being said…

> Or, alternatively, the idea can be broken up into smaller, lower impact changes that still help to address the import system and end user environment maintainability issues, but don't involve breaking backwards compatibility.

+1 on working on *much* better debuggability and discoverability for .pth files first, and then consider their eventual deprecation, replacement, and/or removal.