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