On Wed, Jul 15, 2009 at 5:16 PM, Joachim König<him at online.de> wrote: > 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? When you create an application that uses several libs, and when you create your distribution, you end up pinning a version for each one of your dependency to avoid any problems. While it's workable in a small application to list the dependencies in a text file, and let your users install them manually, it's impossible in bigger applications. Applications based on Zope for example have **hundreds** of dependencies you need to have installed, in very specific versions. If you install a Zope 2 app on your system, and a Zope 3 one, you have good chances of breaking them because the "zope.schema" distribution is incompatible. So either each application ships its own collection of dependencies and ignore site-packages (that's what zope-based applications does with zc.buildout), either they have a way to pick the right version of each package. > >> 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. That's what we have nowadays. python packages installed in different places, and scripts tweaking the path to launch an application with them.
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