[Bug 89694] Re: python-wxtools not usable with wxPython2.8, requires 2.6

wxPython Dev
1

Hi Robin,

I was wondering why the python-wxtools in the debian repository are
independent of the wxpython version? I can understand for the
python-wxversion as there could be only one package, which is is a
fixed path. The python-wxtools I think are not version independent. I
mean it is possible that they include tools with 2.8 which are not
compatible with 2.6 So shouldn't the name be python-wxtools2.8? (If
for example one of the python-wxtools uses AUI, it would break on 2.6,
or back in time "from wxpython import *" to "import x")

For example now on the universal MOTU repositories of Debian (so
including Ubuntu) there is a conflict in Feisty and it wouldn't be if
the name of python-wtools would be name dependent. Now I can't install
the python-wxtools in Feisty as they are dependent on wxpython2.6 That
should not be a problem but in the MOTU repositories wxPython2.8
conflicts with wxPython2.6 I don't know if the same is true for the
wxCommunity repositories. I think it is a bug in the packaging of
wxPython on MOTU. Two versions should be able to coexist. It is
strange because libwxgtk2.8 can coexist with libwxgtk2.6 in MOTU.

As Ubuntu is becoming more popular, it would be nice if wxPython as a
real cross-platform toolkit works well. Now in Feisty people will have
problems if they need for a certain program to use 2.6 and for another
program 2.8 (I had now a problem as I wanted to use Feisty with
wxpython2.8, python2.5 and XRCed. I run into conflicts and solved it
by using the MOTU repositories and installing XRCed manually. Of
course I can not expect this of eg a SPE user who wants to work with
XRCed.) Of course people could add the wxcommunity repositories, but
generally it is not recommended for end users to add third party
repositories out of security reasons.

As a solution I propose:
- in general: name the tools with version number: python-wxtools2.8
- for MOTU: wxPython2.8 should not conflict with 2.6 (this is not your task)

What do you see as the best patch for this problem? As now you are
working on the Feisty wxcommunity repository, I thought now it is the
right time to solve this.

Stani

PS Please reply to me in cc as well. I only follow the weekly diggest
of wxpython-dev.

···

---------- Forwarded message ----------
From: Matthias Klose <doko@ubuntu.com>
Date: Mar 7, 2007 4:42 PM
Subject: [Bug 89694] Re: python-wxtools not usable with wxPython2.8,
requires 2.6
To: spe.stani.be@gmail.com

we are after UVF. so making the new version the default will not happen
for feisty; please attach a patch to this report, if you want to see
something fixed in feisty.

** Changed in: wxwidgets2.6 (Ubuntu)
   Importance: Undecided => Low
       Status: Unconfirmed => Confirmed

--
python-wxtools not usable with wxPython2.8, requires 2.6
https://launchpad.net/bugs/89694

--
http://pythonide.stani.be

2

SPE Stani's Python Editor wrote:

Hi Robin,

I was wondering why the python-wxtools in the debian repository are
independent of the wxpython version? I can understand for the
python-wxversion as there could be only one package, which is is a
fixed path. The python-wxtools I think are not version independent. I
mean it is possible that they include tools with 2.8 which are not
compatible with 2.6 So shouldn't the name be python-wxtools2.8? (If
for example one of the python-wxtools uses AUI, it would break on 2.6,
or back in time "from wxpython import *" to "import x")

They are version independent, for two reasons. 1. They are common files that would conflict if multiple versions are installed, /usr/bin/pycrust for example. 2. They are only very small scripts like the following that import from the wx package and call a single function there, so no matter which version of wxPython is set as the default version it should always work because the real code being executed is in the version specific wxPython packages.

···

------------------------------
#!/usr/bin/python2.4

from wx.py.PyCrust import main
main()
------------------------------

The only problems that might arise is if a newer python-wxtools is installed but an older wxPython is the default, and that version doesn't have the implementation of some new tool. But that hasn't happened since we started using this packaging scheme in 2.4 or 2.5.

For example now on the universal MOTU repositories of Debian (so
including Ubuntu) there is a conflict in Feisty and it wouldn't be if
the name of python-wtools would be name dependent. Now I can't install
the python-wxtools in Feisty as they are dependent on wxpython2.6 That
should not be a problem but in the MOTU repositories wxPython2.8
conflicts with wxPython2.6

I expect that is a bug in their build or in the control file. I checked the one in our CVS and the only relevant tags on the python-wxtools package is that it is dependent on the same version of wxPython (so it will need to be installed too, but doesn't need to be the default version) and that it conflicts with and replaces the former package names from before the switch to this packaging scheme. Here is that section of the file, ("=V" will be replaced with the 2 part version number as part of the build process, and "=U" will be replaced with "-ansi" for non-unicode builds):

Package: python-wxtools
Architecture: all
Section: python
Depends: python-wxgtk=V=U
Conflicts: wxpython2.6-0
Replaces: wxpython2.6-0, libwxgtk2.4-python, wxpython2.4-1
Description: wxWidgets Cross-platform C++ GUI toolkit (wxPython common files)
  wxWidgets (formerly known as wxWindows) is a class library for C++ providing
  GUI components and other facilities on several popular platforms (and some
  unpopular ones as well). For more information see http://wxwidgets.org
  .
  This package provides support utilities and common files for wxPython=V=U.
  If you wish to use xrced you'll also need the =PY-xml package installed.

I don't know if the same is true for the
wxCommunity repositories. I think it is a bug in the packaging of
wxPython on MOTU.

I think so too.

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