Prev: Checking that 2 pdf are identical (md5 a solution?)
Next: Multiprocessing zombie processes
From: Peo on 24 Jul 2010 11:56
Hi,

I'm writing a library for doing sysadmin tasks at my workplace. These
kind of
scripts have a tendency to live for decades and I want to make sure
that I don't break anything when I'm updating the library.

My current plan is to call the library something like 'foo1' and
import it into
scripts like 'import foo1 as foo'. Releases that change the API would
be installed
as 'foo2', 'foo3' and so on. This works fine but it will be quite
difficult
to create new releases (documentation and library code are littered
with
references to 'foo1').

Is there some other smart way to do acheive this?

Thanks / Paul
From: Carl Banks on 24 Jul 2010 14:57
On Jul 24, 8:56 am, Peo <paul...(a)gmail.com> wrote:
> Hi,
>
> I'm writing a library for doing sysadmin tasks at my workplace. These
> kind of
> scripts have a tendency to live for decades and I want to make sure
> that I don't break anything when I'm updating the library.
>
> My current plan is to call the library something like 'foo1' and
> import it into
> scripts like 'import foo1 as foo'. Releases that change the API would
> be installed
> as 'foo2', 'foo3' and so on. This works fine but it will be quite
> difficult
> to create new releases (documentation and library code are littered
> with
> references to 'foo1').
>
> Is there some other smart way to do acheive this?

The typical way to do this is to delegate responsibility to load the
most recent release to another module. Create a module called foo.py,
and it have it import all the objects from the most recent release
module. IOW, you should have a foo.py module that looks like this:


from foo1 import *


Which you update whenever there's a new release. Then in your code
you simply use:


import foo


This is, incidentally, one of the few cases where it's recommended to
use from module import *.


Carl Banks
From: Lawrence D'Oliveiro on 25 Jul 2010 05:50
In message
<2cb0c88b-58ea-4704-8578-2ebd766f1269(a)t10g2000yqg.googlegroups.com>, Peo
wrote:

> My current plan is to call the library something like 'foo1' and
> import it into scripts like 'import foo1 as foo'. Releases that change the
> API would be installed as 'foo2', 'foo3' and so on. This works fine but it
> will be quite difficult to create new releases (documentation and library
> code are littered with references to 'foo1').

I don't understand why this is a problem. The references to “foo1” are
because it is “foo1” that implements those facilities, is it not? When
“foo2” comes along, you will introduce that name where specifying the
facilities specific to it, will you not? Where both modules provide the same
facilities, you will have to mention both names, and only in those cases.

I don't see how you can possibly short-cut this process and still produce
correct documentation.
From: Chris Withers on 30 Jul 2010 14:17
Peo wrote:
> Is there some other smart way to do acheive this?

Just turn them info python packages, and use buildout, pip or some other
python package management tool to create the versions.

You may, of course, just be able to svn the lot of them...
(then you don't need to worry about numbering them at all)

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
 | 
Pages: 1
Prev: Checking that 2 pdf are identical (md5 a solution?)
Next: Multiprocessing zombie processes