[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#755757: transition: wxpython3.0



On Tue, Aug 19, 2014 at 07:12:30PM +0400, Dmitry Shachnev wrote:
> While this is not directly related to the transition, can you please
> use the correct package naming for python packages (at least in
> future)?
> 
> For example, you recently (~ 2 days ago) added a new binary package:
> 
> * New binary package python-gtk-media3.0 for wx.media.  (Closes: #722687)

There's actually a typo in the changelog entry - the new module was
really called python-wxgtk-media3.0, which at least includes "wx".

> Per the Python policy [1], it should have been named python-wx.media,
> not python-gtk-media3.0 (we have these naming rules so that it's
> easier to guess which package a module is in).
> 
> [1] https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names

Sorry for not following the policy - I hadn't really thought about the
name much, and just named it liked the C++ runtime for the media stuff.

However, python-wx.media wouldn't work with how the parallel installs
of different wxPython release series are handled - you can select the
version (or versions) of wxPython your app supports via the wxversion
module, and then "import wx" will import one of those (or fail if not
available).

The transition to a new wxPython version would be a lot more painful
without the ability to parallel install.  And the wxversion mechanism is
provided by upstream, so it is something which upstreams of packages
using wxPython will expect to be available - renaming the wx modules to
include the version would mean we'd have to patch a lot of packages.

So the binary package name needs to include "3.0" (while there's no
package of wx.media for wxPython 2.8, that's mostly because it would
have a very short life at this point, and there will be one for wxPython
3.2).

It probably should include "gtk" too, as you can build other flavours
of wx on Debian, such as wxX11 and wxMotif, and there's apparently a
wxQt in the works:

http://docs.wxwidgets.org/trunk/page_port.html#page_port_wxx11
http://docs.wxwidgets.org/trunk/page_port.html#page_port_wxmotif
http://wiki.wxwidgets.org/WxQt

We don't currently package any of these for Debian, but I can see
that once it's a bit more mature, wxQt would be desirable to provide a
more consistent look-and-feel for wx-apps on a KDE desktop, and perhaps
wxX11 would be useful for lower-end systems.

I don't see anything obvious in the Python Policy about what to do
when multiple binary packages can provide the same module.  I guess
something like python-wx.media-wx3.0-gtk would be a better choice (but
probably too much pain to change at this point for 3.0).

Perhaps the new package should at least have "Provides: python-wx.media"
(and python-wxgtk3.0 have "Provides: python-wx").  That would make it
easier to locate them from the module name, and allow packages to depend
on wxPython without hard wiring a particular version (or port).

BTW, I'd welcome involvement from Python people in maintaining wxPython.
I'm not a big Python user myself (as you can probably tell).  In 3.0,
wxPython is a separate source package to the C++ wxWidgets library,
which has simplified that packaging significantly.

Cheers,
    Olly


Reply to: