[Pythonmac-SIG] The versioning question...

[Bob Ippolito]

On Dec 27, 2004, at 5:29 PM, Chris Barker wrote:

> Eric Nieuwland wrote:
>
>> Would it be an idea to submit a PEP for extending the 'import' 
>> keyword?
>
> As I mentioned, my read on this is that it's not going to happen at 
> the python level, at least not for a while. This is based on various 
> threads in c.l.p, and maybe python-dev. So, while I still think it's 
> important, I'm not going to try to work for it now.
>
> Even with wxPython, there was some resistance to the versioning idea, 
> which as far as I could tell boiled down to:
>
> "It would be much better to keep packages backward compatible"
>
> Which is also kind of what Bob I. said about PyObjC.

Personally I think the wx versioning mechanism is bad.  It should've 
just been done with module names.  Importing wx directly could 
reference the last version that was installed, and wx_2_4 could 
reference some specific version.  The current versioning API is too 
"magical" and provides no means for static analysis without 
special-casing exactly the wx case.  Then again, wx already does a lot 
of ridiculous magical things anyway that wreak havoc on application 
packagers, so why not make the mess even bigger?  More fun for us!  
</sarcasm>

> However, while backward compatibility is great, you are going to want 
> to break it some time. In the wxPython case, there was a lot that 
> changed between 2.4.2 and 2.5.1 and 2.5.2, etc. This was an extreme 
> case, but while maybe it would be a good idea to keep backward 
> compatibility from 2.4.* to 2.5*, at some point, maybe version 3.0, 
> you'll want to break it, and then it would be good to have a system in 
> place.

That's when you change the name of the top level module or package...  
It's the only solution that actually works, but people like to cry 
about it because it's ugly :)

> I just seems obvious to me that you should be able to upgrade a 
> component on your system, whether it be a library, or a python module, 
> without breaking anything that depends on the older component. That's 
> why we have version numbers on dynamic libs. Whether it was Apple's 
> fault or not, it's still been a pain that I can't just upgrade python 
> on my OS-X box. What If Apple some day included PyObjC version X.y and 
> uses it for some system components. Wouldn't you like to be able to 
> upgrade to PyObjC version W.z on your own schedule, not Apple's?

Upgrading is almost unilaterally a bad idea.  Even backwards compatible 
libraries can cause breakage in applications that depend on misfeatures 
of a previous version.  What you really want is to be able to run 
multiple versions of stuff in parallel, and that pretty much works.  
Yes, you need to patch Python if you want the older version to still be 
able to compile extensions, and that's more or less our fault.  Other 
than that, having parallel Pythons works just fine.

For third party packages, Apple seems to install them in the normal 
place (directly in site-packages or some equivalent referenced by a 
pth).  It would be possible to upgrade these by normal means 
(replace).. however, by doing that, you're potentially breaking any 
installed software that uses it.  If you want bleeding edge, or the 
dusty old past, you MUST run it in parallel, whether that's by having a 
separate Python installation or a way of flipping around sys.path.  
Except for modules that are specifically designed to run in parallel 
with other versions of themselves (by naming convention), you simply 
CAN NOT have two versions of the same thing available.

-bob