On Sun, 29 Jan 2006 00:07:29 -0800, Raymond Hettinger wrote: > [EMAIL PROTECTED] >> I'm a newbie experimenting with Python. I want to incrementally develop >> a module called 'circle'. > . . . >> Basically I want to decouple the version of my file from the name of >> the module. >> >> Is there a *simple* way out of this dilemma.
[snip] > Of course, the right answer is to do what everyone else does. Use a > version control system instead of multiple files. Which is the right answer to a question, but I'm not convinced it is the right answer to the implied question. For serious development, version control systems are the way to go. No arguments from me, we agree. But CVS or similar doesn't help you when you are *distributing* your modules to others. I fear I'm belabouring the obvious, but in case it isn't obvious what I mean, here is a made-up example: 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. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
