F22 System Wide Change: wxPython 3

[Jaroslav Reznik]

= Proposed System Wide Change: wxPython 3 =
https://fedoraproject.org/wiki/Changes/wxPython3

Change owner(s): Scott Talbert <swt(a)techie.net&gt;

Get wxPython 3 packaged and into Fedora. 

== Detailed Description ==
This change proposal aims to get wxPython 3.0 (Python bindings for the 
wxWidgets GUI library) packaged and into Fedora. Currently Fedora has wxPython 
2.8 which has not been updated since 2011. The plan is to make wxPython 3.0 
co-installable with wxPython 2.8, similarly to what has been done with the 
wxWidgets packages (wxGTK and wxGTK3). 

== Scope ==
* Proposal owners:
** Update existing wxPython package so that it is co-installable with wxPython 
3 (currently in progress [1]).
** Get wxPython 3 through the package review process, built, and ensure it can 
co-exist with wxPython 2.8 package.
** If all wxPython-dependent packages get moved to wxPython 3.0, consider 
retiring wxPython 2.8 package.

* Other developers: 
** For maintainers of packages that depend on wxPython: switch the dependent 
packages to use wxPython 3.0.  This can be done package-by-package as time 
permits.  The API hasn't changed much between wxPython 2.8 and 3.0, but some 
changes may be required.
** If a package cannot be moved to wxPython 3, after wxPython 3 is packaged, 
maintainers should verify that their packages continue to use wxPython 2.8 
correctly when wxPython 3.0 is co-installed.  A small change may be required 
to some packages to ensure they select wxPython 2.8 specifically.

* Release engineering: None  
* Policies and guidelines: None 

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1142515
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 17, 2014 at 03:15:58PM +0100, Jaroslav Reznik wrote:
>  == Detailed Description ==
>  This change proposal aims to get wxPython 3.0 (Python bindings for the 
>  wxWidgets GUI library) packaged and into Fedora. Currently Fedora has wxPython 
>  2.8 which has not been updated since 2011. 
Sounds good.

>  The plan is to make wxPython 3.0 
>  co-installable with wxPython 2.8, similarly to what has been done with the 
>  wxWidgets packages (wxGTK and wxGTK3).  
What are the issues involved in updating
everybody to wxPython 3.0?

Zbyszke

[Scott Talbert]

On Thu, 18 Dec 2014, Zbigniew Jędrzejewski-Szmek wrote:

> > The plan is to make wxPython 3.0
> > co-installable with wxPython 2.8, similarly to what has been done with the
> > wxWidgets packages (wxGTK and wxGTK3).
>  What are the issues involved in updating everybody to wxPython 3.0? 
It is certainly doable.  Debian did it recently in Jessie, so we can 
probably look there to see which packages needed patching.  The main 
difference is that they are still using the GTK2 implementation.  Upstream 
wxPython only recently enabled the GTK3 implementation, so I'm a little 
worried that we may come across some bugs.

Are you thinking that we should just go for it and upgrade everybody?

Scott

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 17, 2014 at 07:22:30PM -0500, Scott Talbert wrote:
>  On Thu, 18 Dec 2014, Zbigniew Jędrzejewski-Szmek wrote:
>  
>  >>The plan is to make wxPython 3.0
>  >>co-installable with wxPython 2.8, similarly to what has been done with the
>  >>wxWidgets packages (wxGTK and wxGTK3).
>  >What are the issues involved in updating everybody to wxPython 3.0?
>  
>  It is certainly doable.  Debian did it recently in Jessie, so we can
>  probably look there to see which packages needed patching.  The main
>  difference is that they are still using the GTK2 implementation.
>  Upstream wxPython only recently enabled the GTK3 implementation, so
>  I'm a little worried that we may come across some bugs.
>  
>  Are you thinking that we should just go for it and upgrade everybody? 
I really
don't know. That's why I was asking.

Making them parallel installable is the kind of work which generates more
work later on. I think it might be worthwhile to put the new version
in a buildroot override and rebuild the dependent packages and see what
falls out. It might be less work to fix the few problematic packages.

Zbyszek

[Scott Talbert]

On Thu, 18 Dec 2014, Zbigniew Jędrzejewski-Szmek wrote:

> >>> The plan is to make wxPython 3.0
> >>> co-installable with wxPython 2.8, similarly to what has been done with the
> >>> wxWidgets packages (wxGTK and wxGTK3).
> >> What are the issues involved in updating everybody to wxPython 3.0?
> >
> > It is certainly doable.  Debian did it recently in Jessie, so we can
> > probably look there to see which packages needed patching.  The main
> > difference is that they are still using the GTK2 implementation.
> > Upstream wxPython only recently enabled the GTK3 implementation, so
> > I'm a little worried that we may come across some bugs.
> >
> > Are you thinking that we should just go for it and upgrade everybody?
>  I really don't know. That's why I was asking.
>
>  Making them parallel installable is the kind of work which generates more
>  work later on. I think it might be worthwhile to put the new version
>  in a buildroot override and rebuild the dependent packages and see what
>  falls out. It might be less work to fix the few problematic packages. 
Well, none of the dependent packages should need to be rebuilt.  Instead, 
we would need to build the new wxPython and then test each dependent 
package to see if anything breaks.  That is certainly doable though.

Scott

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 17, 2014 at 08:16:14PM -0500, Scott Talbert wrote:
>  On Thu, 18 Dec 2014, Zbigniew Jędrzejewski-Szmek wrote:
>  
>  >>>>The plan is to make wxPython 3.0
>  >>>>co-installable with wxPython 2.8, similarly to what has been done with
> the
>  >>>>wxWidgets packages (wxGTK and wxGTK3).
>  >>>What are the issues involved in updating everybody to wxPython 3.0?
>  >>
>  >>It is certainly doable.  Debian did it recently in Jessie, so we can
>  >>probably look there to see which packages needed patching.  The main
>  >>difference is that they are still using the GTK2 implementation.
>  >>Upstream wxPython only recently enabled the GTK3 implementation, so
>  >>I'm a little worried that we may come across some bugs.
>  >>
>  >>Are you thinking that we should just go for it and upgrade everybody?
>  >I really don't know. That's why I was asking.
>  >
>  >Making them parallel installable is the kind of work which generates more
>  >work later on. I think it might be worthwhile to put the new version
>  >in a buildroot override and rebuild the dependent packages and see what
>  >falls out. It might be less work to fix the few problematic packages.
>  
>  Well, none of the dependent packages should need to be rebuilt.
>  Instead, we would need to build the new wxPython and then test each
>  dependent package to see if anything breaks.  That is certainly
>  doable though. 
That's even better. repoquery tells me that there are 35
packages
requiring wxPython. This seems like a managable number to test, even
for one or two people.

Zbyszek

[Scott Talbert]

On Thu, 18 Dec 2014, Zbigniew Jędrzejewski-Szmek wrote:

> >>>>> The plan is to make wxPython 3.0
> >>>>> co-installable with wxPython 2.8, similarly to what has been done
> with the
> >>>>> wxWidgets packages (wxGTK and wxGTK3).
> >>>> What are the issues involved in updating everybody to wxPython 3.0?
> >>>
> >>> It is certainly doable.  Debian did it recently in Jessie, so we can
> >>> probably look there to see which packages needed patching.  The main
> >>> difference is that they are still using the GTK2 implementation.
> >>> Upstream wxPython only recently enabled the GTK3 implementation, so
> >>> I'm a little worried that we may come across some bugs.
> >>>
> >>> Are you thinking that we should just go for it and upgrade everybody?
> >> I really don't know. That's why I was asking.
> >>
> >> Making them parallel installable is the kind of work which generates more
> >> work later on. I think it might be worthwhile to put the new version
> >> in a buildroot override and rebuild the dependent packages and see what
> >> falls out. It might be less work to fix the few problematic packages.
> >
> > Well, none of the dependent packages should need to be rebuilt.
> > Instead, we would need to build the new wxPython and then test each
> > dependent package to see if anything breaks.  That is certainly
> > doable though.
>  That's even better. repoquery tells me that there are 35 packages
>  requiring wxPython. This seems like a managable number to test, even
>  for one or two people. 
Okay, that's what I'll plan to do then, unless there are major objections. 
I'll probably need a bit of help from the package maintainers, though, as 
I'm sure I won't be able to figure out how to fully test all of the 
dependent packages.

Thanks,
Scott