The issue I'm having is when I install a test/local version of a package in my user site-packages, but the same package is also installed in a system path and has a .pth entry in the system easy-install.pth. It seems that from a path perspective, items under the user path should automatically take precedence over the system path. However, because of the way the paths are rearranged in easy-install.pth, the system path always takes precedence since the easy-install.pth line moves all added items to the front of the path.
So while it seems like the path should be something like:
The path turns out to be:
Is there a reason why the .pth files even contain the final line that rearranges the paths for all the .eggs to be at the start of the system path?
For the time being, my work-around is to manually add a .pth file to my user site-packages path for each item in site-packages as well, and add the lines needed so that when the system easy-install.pth is processed, it doesn't move all:
import sys; sys.__plen = len(sys.path) <my custom entries for each item in user site packages> import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)
All of that is required, because without it, sys.__egginsert will still be unset, and when site.py processes the system path, items in easy-install.pth will be moved above any user .pth items as well.
However, ideally it seems like this path should automatically have precedence over system packages, and it would if not for this line in the various easy-install.pth files:
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)
I guess I just find myself wondering what is the purpose of the above line in easy-install.pth files (for python3, but apparently not python2), and why not just keep the path in the order that site.py would add them.
Brian Allen Vanderburg II