> Linux distros approach to handling this is terrible because they dump all their system packages into a single global site-packages, leading to the every growing sys.path problem that Barry is concerned about.

> However, that's entirely the fault of distro packaging policies, and can be remedied in a far superior way by switching distros to a model where they create a venv per application, and then use .pth files to link in the system packages that they actually want visible to that application.

I'm curious about this since it doesn't make sense to me. Dumping all packages at the top level in /usr/lib/pythonX.Y/site-packages means exactly zero .pth files. Wouldn't putting each module in its own directory, with all the directories necessary for a given app added to the path of a venv for that app mean strictly more .pth files, and a sys.path as long as the list of dependencies for that app? Whilst this would certainly be more flexible for keeping multiple versions of packages around as required by different apps, I don't see that it would decrease startup time at all - more folders need to be searched for each import, not less, and a recursive hierarchy of .pth files would need to be parsed at startup as each package pulled in the directories of its own dependencies. A flat structure like most linux distros use would seem like it would be as efficient as you could get, unless you think that searching through a larger list of strings for the right one is slower than opening a tree of .pth files.