On Wed, Jul 15, 2009 at 5:16 PM, Joachim König<h...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
