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

Discussion in 'Python' started by bobueland@yahoo.com, Jan 28, 2006.

  1. Guest

    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.
    , Jan 28, 2006
    #1
    1. Advertising

  2. 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
    Kirk McDonald, Jan 28, 2006
    #2
    1. Advertising

  3. Paul Rubin Guest

    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.
    Paul Rubin, Jan 28, 2006
    #3
  4. Xavier Morel Guest

    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.
    Xavier Morel, Jan 28, 2006
    #4
  5. Guest

    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
    , Jan 28, 2006
    #5
  6. 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
    Kirk McDonald, Jan 28, 2006
    #6
  7. Roy Smith Guest

    In article <>,
    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.
    Roy Smith, Jan 28, 2006
    #7
  8. On Sat, 28 Jan 2006 23:13:12 +0100, Xavier Morel wrote:

    > 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.
    Steven D'Aprano, Jan 28, 2006
    #8
  9. Roy Smith Guest

    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.
    Roy Smith, Jan 29, 2006
    #9
  10. Peter Hansen Guest

    Roy Smith wrote:
    > 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
    Peter Hansen, Jan 29, 2006
    #10
  11. []
    > 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
    Raymond Hettinger, Jan 29, 2006
    #11
  12. On Sun, 29 Jan 2006 00:07:29 -0800, Raymond Hettinger wrote:

    > []
    >> 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.
    Steven D'Aprano, Jan 29, 2006
    #12
  13. Xavier Morel Guest

    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.
    Xavier Morel, Jan 29, 2006
    #13
  14. Robert Kern Guest

    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


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
    Robert Kern, Jan 29, 2006
    #14
  15. On Sun, 29 Jan 2006 20:07:25 +1100, Steven D'Aprano
    <> declaimed the following in
    comp.lang.python:

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


    Well... You could stop using a common library location, and store
    the library with the application install directory (presuming you aren't
    dumping all those into a common directory also). Then ensure that the
    application install directory is the first item on the search path --
    and it should only find the version applicable to the application.

    Otherwise, I'd suggest you have a problem with the installer -- not
    with Python: your installer is responsible for looking for previous
    versions and identifying the version (via some internal variable,
    perhaps), then determining if an overwrite is safe, or if a total
    mismatch applies.
    <html>
    <body>
    <tt>-- <br>
    &nbsp;&gt; ============================================================== &lt;<br>
    &nbsp;&gt;&nbsp;&nbsp; &nbsp; | Wulfraed&nbsp; Dennis Lee Bieber&nbsp; KD6MOG &lt;<br>
    &nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bestiaria Support Staff&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<br>
    &nbsp;&gt; ============================================================== &lt;<br>
    &nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Home Page: &lt;<a href="http://www.dm.net/~wulfraed/" eudora="autourl">http://www.dm.net/~wulfraed/</a>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<br>
    &nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Overflow Page: &lt;<a href="http://wlfraed.home.netcom.com/" eudora="autourl">http://wlfraed.home.netcom.com/</a>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<br>
    </body>
    </html>
    Dennis Lee Bieber, Jan 29, 2006
    #15
  16. On Sun, 29 Jan 2006 19:03:30 GMT, Dennis Lee Bieber
    <> declaimed the following in comp.lang.python:


    ACK! What did Eudora do to my shared (with Agent) signature files!

    > <html>
    > <body>
    > <tt>-- <br>
    > &nbsp;&gt; ============================================================== &lt;<br>
    > &nbsp;&gt;&nbsp;&nbsp; &nbsp; | Wulfraed&nbsp; Dennis Lee Bieber&nbsp; KD6MOG &lt;<br>

    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
    Dennis Lee Bieber, Jan 30, 2006
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. VisionSet

    Decoupling musing

    VisionSet, Nov 20, 2005, in forum: Java
    Replies:
    5
    Views:
    357
    Andrew McDonagh
    Nov 20, 2005
  2. George Sakkis

    Decoupling fields from forms in Django

    George Sakkis, May 10, 2006, in forum: Python
    Replies:
    0
    Views:
    284
    George Sakkis
    May 10, 2006
  3. Alan Woodland

    Decoupling classes

    Alan Woodland, Apr 25, 2006, in forum: C++
    Replies:
    4
    Views:
    1,561
    Alan Woodland
    Apr 25, 2006
  4. V Green
    Replies:
    0
    Views:
    812
    V Green
    Feb 5, 2008
  5. PA Bear [MS MVP]
    Replies:
    0
    Views:
    914
    PA Bear [MS MVP]
    Feb 5, 2008
Loading...

Share This Page