wxversion issue

wxPython Dev
1

Hi,

In less than three days, I detected three issues in the new wxPython flavour,
and I am an amateur. I'm a little bit sorry for having reopened the wxversion
debate.

To my previous post (about wxversion.require), Robin Dunn replied:

That is by design. It is meant to be used only once, at the very
begining of an application.

When I read it, the answer became quite clear to me (and logical). I have
to select the the wx-version at the start of an application. Unfortunatelly,
I have my own lib, some modules of that lib have an import wx
statement, they do not knew anything about the wx-version. Naively,
and just naturally, I thought it would be a good idea to inform these modules
which version they have to use.

At the present state I see the situation like this.
1) I use import wx everywhere as I was just doing up to now, just
having a more bloated site-package directory.
2) If I use this new feature, once again I have to update
my lib in the same way I updated my lib to a new wxPython
version. I do not see how I can update my lib for a future non existing
version. Beside this, informing these modules about the version to
use is bad, version mixing and ...)
In both variants, the versioning mechanism does not bring something
interesting.

What to do? I do not know. I have just the feeling, wxPython
takes the wrong way. Thinks are happening to fast, there are too
many changes and structural changes in every version. A newer
version has new widgets and bugs fixes, but also bugs in new widgets
and incompatibilites.

I think, from an end user point of view, what wxPython needs is some
stabilization. Versioning must be re-thought, if it has been once deeply
thought. Arguments like, we have introduced versioning, but do not
use it if you plan to create windows executable, are not serious.

This applies to the "management" of wxPython, not to the lib itself.
After 2 (?) years of wxPython use, it seems the development is more
based on a trial and error process, than on a deep thinking. In one
sense it is not normal that such attentions are coming from end user
like me.
I french, we say something like "hunting to many hares at the some
time".

I will add, that I'm very happy with the actual 2.5.2.8 version. It looks
stable, it is what a final wxPython 2.5.0.0 should have been.

Regards.
Jean-Michel Fauth, Switzerland

2

Jean-Michel Fauth wrote:

Hi,

In less than three days, I detected three issues in the new wxPython flavour,
and I am an amateur. I'm a little bit sorry for having reopened the wxversion
debate.

To my previous post (about wxversion.require), Robin Dunn replied:

That is by design. It is meant to be used only once, at the very begining of an application.

When I read it, the answer became quite clear to me (and logical). I have
to select the the wx-version at the start of an application. Unfortunatelly,
I have my own lib, some modules of that lib have an import wx
statement, they do not knew anything about the wx-version. Naively, and just naturally, I thought it would be a good idea to inform these modules
which version they have to use.

If they have version specific code then they should check wx.VERSION. If they are generic enough then they can just do nothing besides import wx. Or the library modules can just trust the aplication that is using them to have imported the right version of wxPython. Or you can version your library modules as well in a similar way and use the sys.path to control which of them is imported based on the version of wxPython that is already imported...

At the present state I see the situation like this. 1) I use import wx everywhere as I was just doing up to now, just
having a more bloated site-package directory.
2) If I use this new feature, once again I have to update
my lib in the same way I updated my lib to a new wxPython
version. I do not see how I can update my lib for a future non existing
version. Beside this, informing these modules about the version to
use is bad, version mixing and ...)
In both variants, the versioning mechanism does not bring something
interesting.

Versioning allows an app to have some choice on which version of wxPython to import, if there happen to be more than one installed. They can also choose to not use wxversion and just use whatever is the default version. That is the functionality we've had up until now and for much of the time (except 2.4 -> 2.5) it works fine with only minor annoyances between versions. The only difference now is that it is possible to have a non-default version installed side by side with the default version.

What to do? I do not know. I have just the feeling, wxPython
takes the wrong way. Thinks are happening to fast, there are too
many changes and structural changes in every version. A newer
version has new widgets and bugs fixes, but also bugs in new widgets
and incompatibilites.

I think, from an end user point of view, what wxPython needs is some
stabilization. Versioning must be re-thought, if it has been once deeply
thought.

I've been doing little else for the past 6 weeks or so.

Arguments like, we have introduced versioning, but do not
use it if you plan to create windows executable, are not serious.

The simple fact is that it is not needed when making bundled apps, because they will already have included in the bundle the version (and only that version) of wxPython that the developer wants. wxversion is for apps that are to be run from their .py file, in environments where more than one version of wxPython is installed.

This applies to the "management" of wxPython, not to the lib itself.
After 2 (?) years of wxPython use, it seems the development is more
based on a trial and error process, than on a deep thinking. In one
sense it is not normal that such attentions are coming from end user
like me.
I french, we say something like "hunting to many hares at the some
time".

If there were 2 or 3 more people like me working full time on wxPython and with frequent face to face contact then we could probably manage to have a more structured development process. But with just me and several hundred "hares" at any one moment needing attention there is no other way that wxPython can make any progress at all.

On the flip side, there should be some comfort in the fact that every one of my "hares" has a wx in front of it's name, and that my attention is not split between working on wxPython and feeding my family.

I will add, that I'm very happy with the actual 2.5.2.8 version. It looks
stable, it is what a final wxPython 2.5.0.0 should have been.

If you only install one 2.5.3 runtime and don't use wxversion then from the perspective of your code the usage will be exactly the same as in 2.5.2.8.

ยทยทยท

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

3

Robin Dunn wrote:

Jean-Michel Fauth wrote:

Versioning allows an app to have some choice on which version of wxPython to import, if there happen to be more than one installed. They can also choose to not use wxversion and just use whatever is the default version. That is the functionality we've had up until now and for much of the time (except 2.4 -> 2.5) it works fine with only minor annoyances between versions. The only difference now is that it is possible to have a non-default version installed side by side with the default version.

In that case, perhaps there could be a 'wx.prefer' method that uses one of the specified versions if it is available, but, if it is not, then merely prints a warning before continuing on with the default version.

Although I'm still trying to decide if that would actually be useful behaviour or not. . .

Cheers,
Nick.