Multiple wxPython versions

Jean-Michel_Fauth · April 21, 2004, 2:55pm

I do not think, there is any valid and/or serious reason
to change anything for the while.

As a *win* developer, switching from one wxPy version
to one another can simply be done by a directory renaming.
(a two-five lines Python script).

The actual discussion is a little hot, because the switch
wxPy24* -> wxPy25 has introduced a lot of changes
(I think for the best).

wxPy developers, you have to face one point.wxPy25 is
new and it is hardly backcompatilble with previous versions.
There are not only changes in the wxPy library (new classes /
Widgets, new methods like self.Bind(...) or improved
methods like the dc.drawingXY functions, but also a new and
stronger interaction between wxPy and Python. All the
classes derive from object and so all are now "new-style classes
(see Migration Guide).

Did anybody try the get, set properties within wxPython classes?
I do, it is working very well. (Just thinking about this,
there are no exemples in the demo/distibution)

To be short, I would say wxPy25 is a new world. I do
not think it will take a long time, until all users have switched.
If not possible, keeping two versions of the same application,
is probably the easiest solution.

Just my opinion. Regards.

Jean-Michel Fauth, Switzerland

Paul_McNett · April 21, 2004, 3:22pm

Jean-Michel Fauth writes:

Did anybody try the get, set properties within wxPython
classes? I do, it is working very well. (Just thinking about
this, there are no exemples in the demo/distibution)

Yes, I'm doing this with great success. I've even extracted out
some common window styles and made them properties, such as
BorderStyle and Alignment.

···

--
Paul

Chris_Barker1 · April 22, 2004, 12:35am

Jean-Michel Fauth wrote:

I do not think, there is any valid and/or serious reason
to change anything for the while.

we should change it now, or not bother

As a *win* developer, switching from one wxPy version
to one another can simply be done by a directory renaming.
(a two-five lines Python script).

it can be done this way on all platforms, but it means that at any one moment, there is only one version in use, and it can't be specified by the app.

The actual discussion is a little hot, because the switch
wxPy24* -> wxPy25 has introduced a lot of changes

Exacly why we should do it now or never.

To be short, I would say wxPy25 is a new world.

Right, which is why this is such an obvious issue right now. IN teh future, who is to say we won't have a similar issue with wxPy35 ?

I do
not think it will take a long time, until all users have switched.
If not possible, keeping two versions of the same application,
is probably the easiest solution.

Exactly why each version of the app should be able to specify which version of wxPython it needs to run with.

Scott David Daniels wrote:

I'd consider using a path file to control this.
In site-packages: "wx24/wx" and "wx24/wxPython" and "wx25/wx" and ...
Also in site-packages:
wxpython.pth

A simple text file with the directory name to use for wxPython
(either wx24 or wx25 in this example).

This still requires for the standard install to have a version name in the path, which is what I"m shooting for. This may solve the "how to ahve a default" problem. If there is a wxpython.pth file, will:

from wx25 import wx
or
from wx24 import wx

still work? This may be the solution...

Robin Dunn wrote:

Chris Barker wrote:

What are your thoughts on option (4) from my previous post:

I think it's a bit too unwieldy, but I'm still thinking about it.

With the suggestion of a wxpython.pth file, I think this could be pretty darn clean:

site-packages/wx24/wx
site-packages/wx24/wxPython
site-packages/wx25/wx
site-packages/wx26/wx

the default set in:
site-packages/wxPython.pth

and then the old style will work, and:
from wx25 import wx
from wx25 import wx.lib.buttons

will work as well!

Samuel Reynolds wrote:

I'd certainly use wxpython.pth instead of symlinks, because
it's a single solution that works cross-platform.

yup, I wish I'd thought of it!

Neither symlinks, folder-renaming, nor wxpython.pth solves
this use-case:

- Single installation of single Python version (e.g., 2.3.2)
- Program A requires wx24 (not converted for wx25)
- Program B requires wx25 (converted, so won't run with wx24)
- User runs A
- User runs B (without killing A)

This is EXACTLY the use case I'm trying to accomidate, and I think the above suggestion would work, and it would only require that the import lines specify the version.

It may be resolved on *nix by starting via a shell script
that sets PYTHONPATH, or on Windows via a .bat file that
starts a new cmd shell with the appropriate PYTHONPATH.
But in either case, this approach would require not only
two different versions of wxPython, but two different
installs of Python (even if the same version).

no, it jsut requires that wxPython not be istalled in the standard location, and I REALLY don't like the need for an extra launch script.

Something that allows the app to specify, before it
imports wxPython (or any part of it), what version is
desired, would be preferable.

This is OK, and there have bee a couple of suggestions, but it still seems simpler to jsut have the version specified in the import statement. The one advantage I can see is that this extra step could allow the user to specifiy an environment variable, that would be used if it existed, solving David Fraser's use case. However, as Jean-Michel pointed out, the best solution there might be: "Don't do that", i.e. don't try to make one wxPython program that works with both versions. If we have a nice way to specify versions, there will be little need.

Unfortunately, this would require changes to Python's
import machinery, not just changes to wxPython.

This is NOT going to happen any time soon, so we need a solution that doesn't require changes to Python.

-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@noaa.gov

Roger_Binns · April 22, 2004, 12:44am

> Unfortunately, this would require changes to Python's
> import machinery, not just changes to wxPython.

This is NOT going to happen any time soon, so we need a solution that
doesn't require changes to Python.

Some of us are stuck with Python 2.2 on Linux (Redhat so
Python being changed will take a long time to affect us!

Roger

David_Fraser · April 22, 2004, 5:31am

Jean-Michel Fauth wrote:

I do not think, there is any valid and/or serious reason
to change anything for the while.

As a *win* developer, switching from one wxPy version
to one another can simply be done by a directory renaming.
(a two-five lines Python script).

But this requires some fairly complex knowledge ... I wouldn't expect my users to be able to do this.

The actual discussion is a little hot, because the switch
wxPy24* -> wxPy25 has introduced a lot of changes (I think for the best).

wxPy developers, you have to face one point.wxPy25 is new and it is hardly backcompatilble with previous versions.
There are not only changes in the wxPy library (new classes / Widgets, new methods like self.Bind(...) or improved
methods like the dc.drawingXY functions, but also a new and
stronger interaction between wxPy and Python. All the
classes derive from object and so all are now "new-style classes
(see Migration Guide).

I am happily writing code that uses either version, so it all depends on whether you are using these features or not...

David

Jorge_Godoy · April 22, 2004, 11:50am

I'm sorry, but why can't you install any other RPM or tarball on your Linux
installation? Company policy?

At least Conectiva has upgraded to Python 2.3.3 for its new release...

···

On Qua 21 Abr 2004 21:44, Roger Binns wrote:

Some of us are stuck with Python 2.2 on Linux (Redhat so
Python being changed will take a long time to affect us!

--
Godoy. <godoy@ieee.org>

Samuel_Reynolds · April 22, 2004, 2:27pm

The problem I have with this is that when wx26 comes out,
I have to edit all the files *even if nothing changed*.

Though I suppose I could do it the other way around:
Change all the files up front to do
from wx24 import wx
etc., and remove it as I move them forward.

My preference (by a wide margin) would be a way to say
"this program uses wx25" (or wx24, or wx32, or whatever)
at startup, and have import wx(.xx...) honor that setting.
Or, better still, "this program works with wx22-wx24" or
"this program works with wx25-26".

Then, when I modify a program for a new version, I only have
to change the version(s) in one place: __main__.

I guess a couple of key question (I'm not clear on all the
subtle details of import) would be:
Q: Once a module is imported (i.e., "from wxPython import wx"),
    do later imports of the same module get a ref to the
    previously-imported module? (I believe they do.)
    - If so, then starting the main module with
      "import wxPython25 as wxPython" would take care of
      later "import wxpython" imports.
Q: Once a module is imported (i.e., "from wxPython import wx"),
    do later imports of *submodules* get a ref to the corresponding
    *submodule* of the previously-imported module?
    - if so, then starting the main module with
      "import wxpython25 as wxpython" would take care of
      later "from wxpython import wx" or "import wxpython.xx" imports.

If the answer is Yes to the above, it should be simple enough
to create a routine that...
1. Checks for a "required" version, if specified, and, if not found,
    notifies the user that no supported version was found, so the
    app can't run.
2. Checks for a "preferred" version (or one of a list or range of
    "preferred" or "supported" versions, or any version after an
    "earliest" version), and loads it if found
    ("import wxPython25 as wxPython").
3. Notifies the user that no supported version was found, so the
    app can't run.
This routine would then need to be called *first thing* in the
main module, so that no other module has a chance to import the
wrong version. Or don't call it at all if you don't care.

To work with this routine, the various versions could be installed
as Chris suggested:

    site-packages/wx24/wx
    site-packages/wx24/wxPython
    site-packages/wx25/wx
    site-packages/wx26/wx

with the default set in:
site-packages/wxPython.pth

This takes care of the use case I described (two apps with different
version requirements running at the same time), but requires only
the insertion of the selector routine in the application main module.
I can't think, off-hand, of a way to include the selector routine
in wxPython--unless it can *unload* wxPython and load the selected
version, which should work if no other code has loaded it yet.

- Sam

···

At 2004-04-21 05:35 PM -0700, you wrote:

With the suggestion of a wxpython.pth file, I think this could be pretty darn clean:

site-packages/wx24/wx
site-packages/wx24/wxPython
site-packages/wx25/wx
site-packages/wx26/wx

the default set in:
site-packages/wxPython.pth

and then the old style will work, and:
from wx25 import wx
from wx25 import wx.lib.buttons

will work as well!

__________________________________________________________
Spinward Stars, LLC Samuel Reynolds
Software Consulting and Development 303-805-1446
http://SpinwardStars.com/ sam@SpinwardStars.com

Chris_Barker1 · April 22, 2004, 4:27pm

Roger Binns wrote:

Some of us are stuck with Python 2.2 on Linux (Redhat so
Python being changed will take a long time to affect us!

No one is stuck with any version of Python on RedHat. I gather that Redhat has again been too short-sighted to put:

#!/usr/bin/python2.2

as the #! line in their scripts, but you can certainly put something like:

#!/usr/bin/env python2.3

in yours. I've been doing this for years...I was certainly not going to wait for RedHat before I started using a new Python that 1.5! And I was running RedHat 7.2 until last week, using mostly python2.3 for my stuff.

-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@noaa.gov

Chris_Barker1 · April 22, 2004, 6:47pm

Samuel Reynolds wrote:

The problem I have with this is that when wx26 comes out,
I have to edit all the files *even if nothing changed*.

Only if you want to use wx26...

But I get your point. Personally, I don't have any problem with specifying the version number in each module that is part of a given app, but you have a good point. In particular, if you have a wxPython module that works with both 2.4 and 2.5, for instance, it would be really nice if you could have programs written for 2.4, and programs written for 2.5, both import it, and it would use the same version as the main program (anything else would fail, I'm sure). That means that we'd have to have a way to specify the version needed in the main program, and a :

import wx

would use that version in all other modules.

I think it may be useful to outline what use cases we all want to support, then we can discuss how best to do that. Here is what I've gleaned from the discussion, there may be others, in which case please add them, and some of these might be deemed less important than others.

1) Multiple versions of wxPython being installed at the same time: so that two or more programs, each using a different version could run at once.

2) The ability for the programmer to specify the version used in the code, ideally only on (or before) the first import of wxPython

3) A default version that gets imported with "import wx", just like it's always been

4) The ability to specify the version wanted with an environment variable, so that multiple versions could be easily tested

5) The ability to specify multiple versions that all work, in a ordered list of some sort.

6) The ability to specify a "minimal" version, and higher versions could be used.

For what it's worth, I got a few responses on camp.lang.python. PMW seems to be doing what we may be steering toward, and I think could satisfy all of the above:

Graham Dumpleton wrote:

Check out Pmw (pmw.sourceforge.net) for ideas. It stores stuff under a
root of Pmw, but then has separate directories under that for each version.
Ie., Pmw_1_1, Pmw_1_2, etc. The __init__.py in the root is then a special
lazy loader which by default uses the latest version, but you can specify
a specific version by using a setversion() method. Whatever version you
end up using, everything is still referenced as Pmw.SomeClass rather
than having to hard code the version everywhere.

I'm not sure how they do the setversion() method...you'd have to import wx first, then it would be too late...or maybe that's what he means by a lazy loader. Anyone got PMW installed to check out?

There was also a report that PyGTK does something to handle this as well, anyone got that installed to check out?

And another note:

Rob Nikander wrote:

Also I was using a python module today that behaved differently upon import, depending on a property of "sys". Like:

import sys
sys.coinit_flags = 0
import pythoncom # initializes COM with sys.coinit_flags

This would be a way to borrow and existing module, rather than creating an additional wxpyversion module.

-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@noaa.gov

David_Fraser · April 23, 2004, 10:46am

Chris Barker wrote:

Samuel Reynolds wrote:

The problem I have with this is that when wx26 comes out,
I have to edit all the files *even if nothing changed*.

Only if you want to use wx26...

But I get your point. Personally, I don't have any problem with specifying the version number in each module that is part of a given app, but you have a good point. In particular, if you have a wxPython module that works with both 2.4 and 2.5, for instance, it would be really nice if you could have programs written for 2.4, and programs written for 2.5, both import it, and it would use the same version as the main program (anything else would fail, I'm sure). That means that we'd have to have a way to specify the version needed in the main program, and a :

import wx

would use that version in all other modules.

I think it may be useful to outline what use cases we all want to support, then we can discuss how best to do that. Here is what I've gleaned from the discussion, there may be others, in which case please add them, and some of these might be deemed less important than others.

1) Multiple versions of wxPython being installed at the same time: so that two or more programs, each using a different version could run at once.

2) The ability for the programmer to specify the version used in the code, ideally only on (or before) the first import of wxPython

3) A default version that gets imported with "import wx", just like it's always been

4) The ability to specify the version wanted with an environment variable, so that multiple versions could be easily tested

5) The ability to specify multiple versions that all work, in a ordered list of some sort.

6) The ability to specify a "minimal" version, and higher versions could be used.

This is a great list, I have put some of it in the VersionSelection page on the wiki.

For what it's worth, I got a few responses on camp.lang.python. PMW seems to be doing what we may be steering toward, and I think could satisfy all of the above:

Graham Dumpleton wrote:

Check out Pmw (pmw.sourceforge.net) for ideas. It stores stuff under a
root of Pmw, but then has separate directories under that for each version.
Ie., Pmw_1_1, Pmw_1_2, etc. The __init__.py in the root is then a special
lazy loader which by default uses the latest version, but you can specify
a specific version by using a setversion() method. Whatever version you
end up using, everything is still referenced as Pmw.SomeClass rather
than having to hard code the version everywhere.

I'm not sure how they do the setversion() method...you'd have to import wx first, then it would be too late...or maybe that's what he means by a lazy loader. Anyone got PMW installed to check out?

Yes I think the lazy loader means one version will bail out and import a different version if it detects the requirement. This seems a bit problematic to me.

There was also a report that PyGTK does something to handle this as well, anyone got that installed to check out?

And another note:

Rob Nikander wrote:

Also I was using a python module today that behaved differently upon import, depending on a property of "sys". Like:

import sys
sys.coinit_flags = 0
import pythoncom # initializes COM with sys.coinit_flags

This would be a way to borrow and existing module, rather than creating an additional wxpyversion module.

Would be nice, but then it requires the lazy loading code inside the wx standard module - I think its better outside, because then it can be upgraded etc if the mechanism changes.

David

Samuel_Reynolds · April 23, 2004, 11:19pm

I took a look at the Pmw __init__/loader files.
It looks like they simply use the loader from the most recent
version of Pmw (so the comments say). So the loader can be
easily upgraded as part of a Pmw upgrade.

I can't say I followed the rest of the code, though.

- Sam

···

At 2004-04-23 12:46 PM +0200, you wrote:

Would be nice, but then it requires the lazy loading code inside the wx standard module - I think its better outside, because then it can be upgraded etc if the mechanism changes.

__________________________________________________________
Spinward Stars, LLC Samuel Reynolds
Software Consulting and Development 303-805-1446
http://SpinwardStars.com/ sam@SpinwardStars.com