Decoupling the version of the file from the name of the module.

Steven D'Aprano steve at REMOVETHIScyber.com.au
Sun Jan 29 10:07:25 CET 2006


On Sun, 29 Jan 2006 00:07:29 -0800, Raymond Hettinger wrote:

> [bobueland at yahoo.com]
>> 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.




More information about the Python-list mailing list