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

[bobueland]

I'm a newbie experimenting with Python. I want to incrementally develop
a module called 'circle'. The problem is now that the file name is used
for two purposes. To keep track of the version number and as the name
for the module. So when I develop the first version of my file I have
to call it circle_a.py. The name of the module then automatically
becomes circle_a. But when I develop the next increment and call my
file circle_b.py the module name changes as well.

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.

[Xavier Morel]

bo*******@yahoo.com wrote:

I'm a newbie experimenting with Python. I want to incrementally develop
a module called 'circle'. The problem is now that the file name is used
for two purposes. To keep track of the version number and as the name
for the module. So when I develop the first version of my file I have
to call it circle_a.py. The name of the module then automatically
becomes circle_a. But when I develop the next increment and call my
file circle_b.py the module name changes as well.

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.

You have two choices:

1- Just get rid of the version number in the name (what's the point) and
define a __version__ attribute in the module, that's what is usually done.
2- create a wrapper module called "circle.py" whose content will be
something along the lines of "from your_current_module_with_version
import *"

I'd strongly suggest the first choice, there is no point in giving the
version number into the file name of a module.

[Kirk McDonald]

bo*******@yahoo.com wrote:

I'm a newbie experimenting with Python. I want to incrementally develop
a module called 'circle'. The problem is now that the file name is used
for two purposes. To keep track of the version number and as the name
for the module. So when I develop the first version of my file I have
to call it circle_a.py. The name of the module then automatically
becomes circle_a. But when I develop the next increment and call my
file circle_b.py the module name changes as well.

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.

I would recommend just naming the file circle.py, and defining something
like a variable named __version__ or maybe __revision__ at the top of
the module. Then you can, I don't know, back up your old versions to
other filenames or something.

Or, if you really want to do this right, you could install Subversion. :-)

-Kirk McDonald

[Paul Rubin]

bo*******@yahoo.com writes:

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.

Really, you should use a source control system. That's a program that
tracks the different versions of the files in your program. When one
of your files reaches a state of stability, you "check it in" to a
source repository which then remembers that version. You then go on
editing the file in place. Later, you can restore the old version
from the repository if you need to.

Source control is the only sane way to do what you're trying to do.
Messing around with renaming files to save old versions, as you're
doing, only works for very small, short-lived projects. That scheme
will drive you crazy in short order.

SubVersion (http://subversion.tigris.org) is a popular source control
system, maybe not the best, but compatible with some older widely used
ones. I'd personally choose this one because I have some experience
with it, but it's not ideal. Even if you don't choose to use it, you
might read its online docs, to get a sense of what kinds of problems
these programs try to solve.

There's a newer one called Codeville, written in Python, that I
haven't tried. There are numerous others I won't bother trying to
list. Which one is best is the topic of religious wars, like "the
best editor" or "the best language". Just pick one that you like and
stick with it.

[bobueland]

Xavier Morel wrote:

Just get rid of the version number in the name (what's the point) and
define a __version__ attribute in the module, that's what is usually done.

Thanks Xavier, but as I said I'm newbie and I'm not sure how to do
that. Here's my module

# circle.py
from math import pi

__version__ = '1.0'

def disk(r):
"""Returns the area of the disk with radius r."""
return (pi * r**2)

def test():
print disk(1)
print disk(2)

# end of the module
Now suppose I have make a new version with __version__ = 1.1. What
shall I call this file and (I don't want to overwrite the old file if I
need to go back to it) how do I import it from the shell. Your advice
sounds nice, but I would appreciate if you could give me (or point me
to) a simple example.

Thanks

[Kirk McDonald]

bo*******@yahoo.com wrote:

Now suppose I have make a new version with __version__ = 1.1. What
shall I call this file and (I don't want to overwrite the old file if I
need to go back to it) how do I import it from the shell. Your advice
sounds nice, but I would appreciate if you could give me (or point me
to) a simple example.

Thanks

Before you make a new version, rename circle.py to, e.g., circle-1.0.py,
and then create the new version as circle.py. Then you can access the
new version just like you accessed the old. If you make yet another new
version, then rename the current circle.py as circle-1.1.py, and lather,
rinse, repeat.

However, I'd still look into a version control system like Subversion.
It can do all of this for you.

-Kirk McDonald

[Roy Smith]

In article <11**********************@z14g2000cwz.googlegroups .com>,
bo*******@yahoo.com wrote:

I'm a newbie experimenting with Python. I want to incrementally develop
a module called 'circle'. The problem is now that the file name is used
for two purposes. To keep track of the version number and as the name
for the module. So when I develop the first version of my file I have
to call it circle_a.py. The name of the module then automatically
becomes circle_a. But when I develop the next increment and call my
file circle_b.py the module name changes as well.

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.

Why do you have to change the name of the file each time you come out with
a new version? I think that's where you're going wrong. Put something
*inside* the file to indicated the version number, but keep the name of the
file the same.

[Steven D'Aprano]

On Sat, 28 Jan 2006 23:13:12 +0100, Xavier Morel wrote:

bo*******@yahoo.com wrote:

I'm a newbie experimenting with Python. I want to incrementally develop
a module called 'circle'. The problem is now that the file name is used
for two purposes. To keep track of the version number and as the name
for the module. So when I develop the first version of my file I have
to call it circle_a.py. The name of the module then automatically
becomes circle_a. But when I develop the next increment and call my
file circle_b.py the module name changes as well.

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.

You have two choices:

1- Just get rid of the version number in the name (what's the point) and
define a __version__ attribute in the module, that's what is usually done.
2- create a wrapper module called "circle.py" whose content will be
something along the lines of "from your_current_module_with_version
import *"

I'd strongly suggest the first choice, there is no point in giving the
version number into the file name of a module.

Modules are conceptually like a shared code library, and remember the
awful problem of DLL hell on Windows? In Linux land, the convention is
that libraries have the version number in the file name, so that when you
install a library, it doesn't overwrite any pre-existing versions of the
library. This is a Good Thing.

I haven't been distributing a large number of Python applications to
outsiders, so I don't know how much of a practical problem it is for
Python, but if you have a rapidly changing module, with changes to the
API, this is certainly a theoretical problem, if not a practical one.

If it is not a problem in practice, why not? What do people do to avoid
this?
--
Steven.

[Roy Smith]

bo*******@yahoo.com wrote:

Now suppose I have make a new version with __version__ = 1.1. What
shall I call this file and (I don't want to overwrite the old file if I
need to go back to it)?

Stop everything right now and get yourself some kind of version control
system. CVS (http://ximbiot.com/cvs/wiki/index.php?title=Main_Page) is a
popular one. Subversion (http://subversion.tigris.org/) is a bit newer,
and quickly gaining is popularity. If some other system (Perforce,
ClearCase, RCS, SCCS, etc) is already in use where you are, just use that.
Many IDEs come with something built-in. Which one you pick is a detail,
but it's essential that you use something.

If you don't use some kind of version control system, you end up mired in
thorny questions like the one you ask above. Learning something like cvs
may seem intimidating at first, but believe me, it's impossible to do any
kind of serious software development without one.

[Peter Hansen]

Roy Smith wrote:

bo*******@yahoo.com wrote:

Now suppose I have make a new version with __version__ = 1.1. What
shall I call this file and (I don't want to overwrite the old file if I
need to go back to it)?

Stop everything right now and get yourself some kind of version control
system. CVS (http://ximbiot.com/cvs/wiki/index.php?title=Main_Page) is a
popular one. Subversion (http://subversion.tigris.org/) is a bit newer,
and quickly gaining is popularity.

Listen to Roy. Get a source code control system. Use any one you want,
provided that if your choice is between CVS and Subversion, you use
Subversion. ;-)

-Peter

[Raymond Hettinger]

[bo*******@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.

In the client code, use an import/as statement and update that single
line as needed:

import circle_b as circle

If you don't want to edit the client code every time, the import can be
automated to smartly find the most recently updated version. Build a
list of filenames using your naming convention. Sort them by
modification date. Then, import the most recent one as circle:

names = glob.glob('circle_*.py')
names.sort(key=lambda f: os.stat(f).st_mtime)
newest_name = names[-1]
newest_module, ext = os.path.splitext(newest_name)
circle = __import__(newest_module)

Of course, the right answer is to do what everyone else does. Use a
version control system instead of multiple files.
Raymond

[Steven D'Aprano]

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

[bo*******@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.

[Xavier Morel]

bo*******@yahoo.com wrote:

Now suppose I have make a new version with __version__ = 1.1. What
shall I call this file and (I don't want to overwrite the old file if I
need to go back to it) how do I import it from the shell. Your advice
sounds nice, but I would appreciate if you could give me (or point me
to) a simple example.

Thanks

As Kirk, Roy and Peter suggested (nay, commanded), use a versioning
system, either CVS or Subversion for example (both are quite simple,
Subversion has a 1 click installer for Windows boxes, and there is a
small book/user manual with it so that you're not lost), they'll do what
you need (keep the old versions around "just in case") and much more to
boot. Spending a day or two learning about how the versioning system
you'll have chosen work is an investment that you'll get back tenfold in
no time, so don't get intimidated or scared.

[Robert Kern]

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
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter