[Python-Dev] Re: [Pythonmac-SIG] The versioning question...

[Chris Barker]

Martin v. Löwis wrote:
> No. Normally, packages should aim for backwards compatibility, so that
> applications would only want to specify a minimum version, such as
> 
> import xml
> assert xml.version_info > (0,8,2)

Well, yes, but life is not always so simple, and while, as a rule, 
version 2.3 should be backward compatible with 2.2, I see no reason to 
expect that version 5.0 and version 2.0 will be compatible. Frankly, 
backward compatibility can be a real impediment to progress. (when will 
"true division" be default?)

> If you really want side-by-side installation of different versions,
> and a mechanism to select between them, the package could support
> 
> import xml_0_8_2 as xml
> 
> IOW, "import-as" should be sufficient for what you want to achieve.

This really doesn't work well for complex packages. I was quite involved 
with the debate about versioning for wxPython (and helped drive it 
happening) and that was what I originally proposed. The problem is that 
you have a whole pile of modules and libs and user code that all imports 
the package. There are a LOT of "import wx" lines in the wxPython 
library, and a whole bunch more in a sizable wxPython app. As you 
upgrade, every one of those would have to be changed to

import wx_x_y_z as wx

This was not considered a reasonable solution. Among other things, it's 
really nice to be able to make a small change in just one file, and be 
able to test your app against a new version.

Other approaches were suggested and were used in the past:

- A script that you run to change what version is installed
- An environment variable that you set.
- Whatever else I can't recall.

Personally, I was only going to be really happy with an approach that 
worked at the python level, in one place.

The versioning system that wxPython now has is quite nice, and seems to 
fit most people's needs well. However, it's also quite new, and who know 
what problems will arise. For those interested, here's a synopsis.

http://wiki.wxpython.org/index.cgi/MultiVersionInstalls

Skip Montanaro wrote:
> There's more to it than that:
>     1. Most people simply don't need it.  My first brush with versioning
>        Python modules occurred in the past few months at my current job, and
>        that was mostly so our SWIG'd modules could be released in step with
>        our locally written C++ libraries.  I used Python for ten years
>        before that without ever feeling the need for versioning.

I'm surprised, but I think maturity and complexity has something to do 
with it. The more mature Python and its add-on packages become, the more 
this will be an issue. There was certainly a lot of uproar about 
backward compatible changes in Python itself, another issue that could 
be lessoned by a bit easier accommodation of multiple versions of 
python. (or why, or why did Redhat not put a version on their #! lines? 
  have they yet?)

>     2. I think it will be challenging to come up with a versioning scheme
>        that works for everyone.

This is very true we had a hard enough time coming to a consensus among 
a small group of wxPython developers. I'm not sure we even did anyway, 
Robin just decided on one to implement.

 > To do versioning at work we had to solve
>        issues related to module naming, directory structure, source code
>        control and local build environment tools to make it work.

Wow! that sounds a lot more complex that it has to be, but I'm sure 
there's a lot to what you've done. Note that you've kind of contradicted 
yourself (or at least contradicted Martin). I suspect your versioning 
issues would have been much simpler if Python itself had supported it.

> Write a PEP and put it out for review.  I don't recall seeing this raised in
> the Python community before.

That I'm surprised about. I've seen it (and brought it up) a number of 
times. I know there are a few major packages with roll your own 
versioning systems, wxPython, PyGTK, and PMW to mention a few.

 > I certainly don't think it's something the
> core developers worry about,

This is quite true, and why I haven't bothered with a PEP, but maybe 
I've got the thinking backwards, we need the PEP to get the "important" 
people thinking about it.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov