[Python-Dev] Re: [Pythonmac-SIG] The versioning question...
Chris.Barker at noaa.gov
Tue Dec 28 02:45:24 CET 2004
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.
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.
Christopher Barker, Ph.D.
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
More information about the Python-Dev