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

[Phillip J. Eby]

At 11:38 PM 12/22/2005 +0100, M.-A. Lemburg wrote:
>How do you assure that only one version of the package
>gets loaded into the Python process ?

I went back in the time machine and convinced Guido to make the import 
system only load the first module it finds with a given name.  ;-)

Sorry, couldn't resist.  :)


>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 ?

pkg_resources.VersionConflict is raised at the point of require()-ing 
something that conflicts with something already in the working set.

Note that you might not get a conflict if module A accepts versions >=1, 
and B accepts versions >=2, and you have version 2, and it's the default 
version or was requested by the __main__ program, effectively making it the 
default.

For example, TurboGears specifies requirements for certain modules that are 
also depended on by its dependencies.  I don't remember what they are, but 
for the sake of example I'll say that TurboGears depends on a particular 
version of FormEncode, which is also depended on by SQLObject - which 
TurboGears also requires.  So it's something like this:

TurboGears:
     FormEncode>=0.5dev
     SQLObject>=0.8dev

SQLObject:
     FormEncode>=0.4

If you run a TurboGears-requiring script, it's going to request a newer 
FormEncode, which will then become the default.  SQLObject also gets 
processed for dependencies, since TurboGears requires it, but since the 
default (FormEncode>=0.5dev) is compatible with the SQLObject requirement 
(FormEncode>=0.4), life just goes on with no conflict.

There are currently a few issues with this algorithm, mainly that it 
decides on a "default version" too early; as soon as pkg_resources is 
finished importing, all "default versions" for eggs that are already 
importable on sys.path are established and can't be changed.  In 0.7, I'll 
be doing some work to loosen this so that the default version of a project 
won't be set in stone until an explicit choice is made or until the default 
default version has been imported.


>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 ?

"Playing tricks with sys.path" *is* the standard way to do it; just look at 
what Guido answers every time anybody asks about needing specific versions 
of things.  "The application should just set up its sys.path however it 
needs to" is more or less his standard response.  The pkg_resources module 
just provides you with convenient routines to do what Guido has already 
declared to be the One Obvious Way to do it, i.e. sys.path manipulation.