Doug Hellmann <doug.hellmann@...> writes:
+1 because using versioned subdirectories lets me install apps that may only work under one of the versions of Python I have installed on my system.
I don't follow the reasoning here. If app A only works with Python version 2.5, install it using Python 2.5, and if app B only works with Python version 2.6, install it using Python 2.6. The shebang line will point to the exact Python version (using setuptools, that is), and the executable's location is obviously orthogonal to selecting the proper Python interpreter. If, on the other hand, for whatever reason you want to install the same application A using two different Python interpreters, I think it's fair to say that it's a very unusual need and that Python shouldn't go out of its way to satisfy it (especially if it worsens the experience for everyone else). (I understand that the few applications which are themselves dedicated to package management, such as easy_install or pip, need some kind of multi-versioning of the executable. But, at least for easy_install, it /already/ comes multi-versioned (easy_install-2.6, etc.) and, besides, this situation is the exception, not the rule)
Of course, a possibly better solution would be to have each app in its own directory with its own copy of its dependencies, but virtualenv makes that easy enough.
Yes, so bottom line: if you have very precise and exclusive requirements regarding what ends up where, you might just as well create a virtualenv, or manually override --install rather than require everyone else to switch to a more complicated setup. ~/.local/bin is simple and standard, please don't change that in order to better accomodate a couple of fringe use cases.