Library versions

[Peo]

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

 

[Carl Banks]

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

 

[Lawrence D'Oliveiro]

In message

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.

 

[Chris Withers]

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