Steven D'Aprano wrote: > I distribute two apps, Parrot and Shrubbery. Both rely on a common module, > Spam. Parrot uses version 1 of Spam and Shrubbery uses version 2. For the > sake of the argument, Spam is completely backwards compatible, so I > have no problems with somebody installing Parrot plus Spam version 1, then > installing Shrubbery, where Spam version 2 overwrites the older Spam > module. But if Spam version 1 overwrites version 2, then Shrubbery stops > working. > > The easy answer is to say, "Then don't do that", but that's a terribly > impractical answer. Blaming the user is no real solution either. In > old-time Windows land, installation programs would blindly nuke newer DLLs > with older DLLs all the time. Under Linux, one convention is for shared > libraries to include the version number in the file name, so that newer > libraries weren't blown away by older ones. > > What is the Python solution? Enquiring minds want to know.
http://peak.telecommunity.com/DevCenter/PythonEggs http://peak.telecommunity.com/DevCenter/PkgResources -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
