Modifying and extending wxversion

=== Problem ===

Format of a wxPython version: wx-VERSION [-PORT-CHARTYPE [-FLAVOUR]]

The wxversion module does not work properly. Its functions are able to
select a desired VERSION, but, depending on the installed wxPython
versions, they fail in selecting a given PORT or a given CHARTYPE. If the
PORT selection may not be very important, selecting a correct CHARTYPE
is practically mandatory. An ansi/unicode application may not work with an
unicode/ansi wxPython version.

Illustration:

On my platform, installed are:

wxver = '2.5.5-unicode'
wxver = '2.5.5-ansi'
wxver = '2.6.0-ansi'

wxversion.getInstalled() returns
  ['2.6-msw-ansi', '2.5.5-msw-unicode', '2.5.5-msw-ansi']
which is ok. But,

wxversion.checkInstalled('2.5.5-gtk-ansi')
or
wxversion.checkInstalled('2.6-unicode')
return
  True

Most annoying is the wrong selection of wxPython:
wxversion.select('2.6-unicode')
import wx
print wx.VERSION_STRING, wx.PlatformInfo
gives
  2.6.0.0 ('__WXMSW__', 'wxMSW', 'ansi', 'wx-assertions-on')
which is clearly wrong.

=== my workaround ===

In my test applications, I'm not using wxversion, I implemented
this code.

targetwxversion = ['wx-2.5.5-msw-unicode', 'wx-2.5.5-msw-ansi',
'wx-2.6-msw-ansi']
targetwxversion = ['wx-2.6-msw-ansi', 'wx-2.5.5-msw-ansi',
'wx-2.5.5-msw-unicode']
targetwxversion = ['wx-2.6-msw-unicode']

targethit = False
try:
    #site-packages path
    sitepackagepath = ''
    for e in sys.path:
        if e.endswith('site-packages'):
            sitepackagepath = e
    if sitepackagepath == '':
        targethit = False
    #is targetwxversion a valid path?
    for v in targetwxversion:
        print 'v:', v
        fp = os.path.join(sitepackagepath, v)
        if os.path.isdir(fp):
            sys.path.insert(0, fp)
            targethit = True
            break
        else:
            targethit = False
except:
    targethit = False

if targethit:
    import wx
    print wx.VERSION_STRING, wx.PlatformInfo
else:
    raise RuntimeError("wxPython version not found")

You may notice
- I specify the whole wxPython version name.
- The winner is the version with the lowest list index.

I have to recognize, this is not as versatile as the wxversion.select()
function. It has the merit of simplicity and it works very well. This
short code (!) does not only select the correct version, it also
indicates, if the version is found. You may argue, specifying all
the allowed versions is annoying; in a practical work, you do not
test an application with to many wxPython versions. In one sense,
this is speaking against the multi-version install capability!

== extending wxversion, proposal 1 ==

Addition of a new function, it will be based on the code above
or something similar.

Pros: - simplicity
      - backward compatible
Cons: - does not solve checkInstalled()

wxversion.selectFromList(list_of_allowed_versions)

== extending wxversion, proposal 2 ==

Submitted by Robin Dunn. Modify the select() function and keep
it backward compatible.

wxversion.select("2.6", mustHave="unicode")

Pros: - versatility
Cons: - PORT is still a problem.

I dived into the code. I find it so complicate...

== miscellaneous ==

o wxversion uses fnmatch. Is this module not reseved for unix platforms?
o a class instead of a set of functions?

Jean-Michel Fauth, Switzerland

Jean-Michel Fauth wrote:

=== my workaround ===

In my test applications, I'm not using wxversion, I implemented
this code.

[...]

You should not limit your search to the site-packages dir. The wxPython dirs and wx.pth can exist anywhere on the sys.path and still be imported by Python.

You may notice
- I specify the whole wxPython version name.
- The winner is the version with the lowest list index.

I have to recognize, this is not as versatile as the wxversion.select()
function. It has the merit of simplicity and it works very well. This
short code (!) does not only select the correct version, it also
indicates, if the version is found. You may argue, specifying all
the allowed versions is annoying; in a practical work, you do not
test an application with to many wxPython versions. In one sense,
this is speaking against the multi-version install capability!

== extending wxversion, proposal 1 ==

Addition of a new function, it will be based on the code above
or something similar.

Pros: - simplicity
      - backward compatible
Cons: - does not solve checkInstalled()

wxversion.selectFromList(list_of_allowed_versions)

== extending wxversion, proposal 2 ==

Submitted by Robin Dunn. Modify the select() function and keep
it backward compatible.

wxversion.select("2.6", mustHave="unicode")

Pros: - versatility
Cons: - PORT is still a problem.

Not if you allow mustHave to specify any number of the components after the version number. You can also already specify a list of versions in the first parameter.

I dived into the code. I find it so complicate...

== miscellaneous ==

o wxversion uses fnmatch. Is this module not reseved for unix platforms?

No, it implements unix-style filename pattern matching, but there is nothing platform specific about it.

···

o a class instead of a set of functions?

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