P.J. Eby wrote:
> At 05:16 PM 7/15/2009 +0200, Joachim König wrote:
>> f 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?
>
> Obviously yes, as neither buildout nor setuptools would exist
> otherwise. ;-)
> Nor would Fedora be packaging certain library versions as eggs
> specifically to get certain multi-version scenarios to work.
>
> The specific solutions for handling n*m problems aren't fantastic, but
> they are clearly needed.
I still do not see the need.
IMO the whole obfuscation comes from fact that all versions of all
packages are installed into
one location where python automaticallly looks for packages and then
with a lot of magic the
packages are hidden from the interpreter and only specific requested
versions are made "visible"
to the interpreter at runtime.
Why do the package have to be installed there at the first place?
For an application it would be enough to have an additional directory on
its PYTHONPATH where
the packages required for this application would be installed. So a
package could be installed either
to the common directory ("site-packages") or an application specific
directory (e.g. something like
"app-packages/<appname>/"). This approach has been used by Zope2 with
its "private" lib/python
directory for years.
So one would have to set up the application specific packages before
running the application, but the
whole clutter of uncounted versions of the same package in one directory
could go away. The
"drawback" of this approach would be, that the same version of a package
would have to be installed
multiple times if needed by different applications.
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