Tarek Ziadé wrote: > So basically "site-packages" is a distribution location that is > avoided by everyone because it doesn't > know how to handle multiple versions. I think you overrate the importance of having multiple versions of a package available for the same python interpreter. If you have m different versions of n packages then you could have n**m different combinations for an application so you need a possiblilty to select one combination from n**m possible ones at application startup time. Is this really worth it? > If we had a multi-versions > support protocol, that would > help os packagers and application developers to be friends again imho ;) > > Let's remove site-packages from Python then. The _one_ site-packages folder stands for _one_ python interpreter. All the clever efforts to provide a set of package versions at runtime to an application (that uses the singleton python interpreter) do logically create a new python interpreter with a site-packages folder that contains just the versions of the packages the application needs, unfortunately by mucking with PYTHONPATH and <package>.pth, site.py etc making it very difficult to understand what is happening for the joe average python developer.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4