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

Chris Barker wrote:

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

Not at all. Import wx_x_y_z could do

sys.modules["wx"] = wx_x_y_z

and then all references to

import wx

would automatically resolve to the version that was imported first (or last, depending on your implementation strategy).

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.

Even if the package is not prepared to register itself under a different name also, this one file could modify sys.modules. Or you can have a wx.py that reads

from wx_x_y_z import *

Then, wx.py would be that single file.

The versioning system that wxPython now has is quite nice, and seems to fit most people's needs well.

Very good! Then I don't see a need to change anything in Python.

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.

I don't think a PEP is needed - Python already appears to have everything you need to come up with your own versioning rules.

Regards, Martin

Martin v. Löwis wrote:

Eric Nieuwland wrote:

...

Would it be an idea to submit a PEP for extending the 'import' keyword?

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)

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.

Unless you are doing comparison tests, where it would be nice to be able to state in a generic way that the new implementation should not change answers. May be something like:

import spam[1] as spamnext # next version import spam[0] as spamnow # current version

assert spamnow.Ni() == spamnext.Ni()

--eric