[Distutils] Multiple version support (default installs and plugins)

[M.-A. Lemburg]

Phillip J. Eby wrote:
> At 02:13 PM 12/22/2005 +0000, Paul Moore wrote:
>> On 12/22/05, M.-A. Lemburg <mal at egenix.com> wrote:
>> > Ian Bicking wrote:
>> > > I'm still finding it impossible to use multiple versions of a package
>> > > unless none of them show up in a .pth file (i.e., none are available
>> > > without requiring), I get a VersionConflict.
>> >
>> > This comes up every now and then when discussing the benefits
>> > of easy_install.
>> >
>> > I'd really like to understand what the use case is for having
>> > multiple versions of a package around.
>> >
>> > Note that sys.modules (the registry of loaded modules) does
>> > not support having multiple versions of a module loaded.
>>
>> I think the point is to allow multiple versions to be installed on the
>> system, but allow an individual program, at run time, to specify which
>> one is to be loaded. There will never be more than one version loaded
>> in any specific instance, but if program A requires version 1 of
>> package X, and program B requires version 2 of package X, both can run
>> without needing a reinstall of package X in between.
>>
>> Of course, this is also possible via PYTHONPATH manipulations, or
>> sys.path modifications in the program before doing the import. All
>> setuptools is doing is to provide a common infrastructure for handling
>> this.
> 
> Yes, Paul is correct; supporting multiple programs that use different
> versions of a module is indeed the primary use case.  Also, during
> development and debugging it can be quite convenient to switch versions
> of a dependency back and forth to identify the source of a problem.

Ok, I can see your point.

How do you assure that only one version of the package
gets loaded into the Python process ?

If you use a module A that needs version 1 and at the
same time a module B that requires version 2, how will
this conflict get resolved ?

If you find this feature important enough, shouldn't we
try to get a solution into the standard Python import
mechanism rather than playing tricks with sys.path ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 22 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::