Chris Billington <chrisjbilling...@gmail.com> added the comment:
> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33944> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
