https://bugzilla.suse.com/show_bug.cgi?id=1233687 https://bugzilla.suse.com/show_bug.cgi?id=1233687#c1 --- Comment #1 from Michal Suchanek <msuchanek@suse.com> --- The wxWidgets features do not depend in any way or the version of wxPython nor the version of wxWidgets installed, only on version of wxWidgets used to build wxPython. Thus application that that requires a specific wxWidgets feature available in python might depend on wxWidgets library that has the feature, and on wxPython, even a specific version but there is no dependency that would ensure the feature is available in python. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1233687 https://bugzilla.suse.com/show_bug.cgi?id=1233687#c2 --- Comment #2 from Daniel Garcia <daniel.garcia@suse.com> --- (In reply to Michal Suchanek from comment #1)

The wxWidgets features do not depend in any way or the version of wxPython nor the version of wxWidgets installed, only on version of wxWidgets used to build wxPython.

Thus application that that requires a specific wxWidgets feature available in python might depend on wxWidgets library that has the feature, and on wxPython, even a specific version but there is no dependency that would ensure the feature is available in python.

Do you think that adding some kind of provides could solve this issue? Right now the python311-wxPython package provides: ``` python311-wxPython = 4.1.1-150400.3.8.1 python311-wxPython(x86-64) = 4.1.1-150400.3.8.1 python311-wxWidgets = 4.1.1 ``` I'm thinking about adding a new one, something like: ``` python311-wxWidgets(binding) = 3.1.5 ``` -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1233687 https://bugzilla.suse.com/show_bug.cgi?id=1233687#c3 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(msuchanek@suse.co | |m) | --- Comment #3 from Michal Suchanek <msuchanek@suse.com> --- python311-wxWidgets_API was added in Factory. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1233687 https://bugzilla.suse.com/show_bug.cgi?id=1233687#c5 --- Comment #5 from Stefan Brüns <stefan.bruens@rwth-aachen.de> --- There is more than the wxWidgets version affecting its API, and unfortunately wxWidgets has (IMHO too) many build options affecting its API and ABI. Also, the ABI is not stable even for minor wxWidgets version bumps. While this is less of a problem for TumbleWeed, as most often the API is stable enough for a rebuild to work, Leap is not so lucky (and in general we can't dump a released library version on Leap) - e.g. Leap 15.x is stuck with wxWidgets 3.1.5, which is a pre-release. So the wxPython package should provide (or at least allow) co-installable versions for the various wxWidgets APIs and ABIs. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1233687 https://bugzilla.suse.com/show_bug.cgi?id=1233687#c7 --- Comment #7 from Stefan Brüns <stefan.bruens@rwth-aachen.de> --- (In reply to Michal Suchanek from comment #0)

The wxPython has its own version independent of wxWidgets version the bindings are built against.

However, some applications require wxPython build against new enough wxWidgets, and this dependency cannot be expressed.

Some specific examples should be provided ... -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1233687 https://bugzilla.suse.com/show_bug.cgi?id=1233687#c9 --- Comment #9 from Michal Suchanek <msuchanek@suse.com> --- kicad only recommends wxPython so giving the version for the recommends does nothing in practice. It warns that scripting is not available when wxPython is built against older (or maybe even in any way different?) version of wxWidgets from what kicad uses. This is a more general problem of library wrappers that are not provided by the library upstream and developed independently. There are separate features/bugfixes provided by the underlying library, and separate features/bugfixes of the wrapper. We only have dependency for the latter but not the former. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1233687 https://bugzilla.suse.com/show_bug.cgi?id=1233687#c11 --- Comment #11 from Michal Suchanek <msuchanek@suse.com> --- (In reply to Stefan Brüns from comment #10)

In Tumbleweed the available wxPython version is recent enough, and Leap does not have a recent wxWidgets version anyway. What is the problem you are actually trying to solve here?

To have the correct wxPython installed. (In reply to Stefan Brüns from comment #6)

This is a fairly incorrect description.

Due to the ongoing incompatible changes in wxWidgets the wxPython version strongly correlates with the wxWidgets version (or at least a very small version range).

You can not build e.g. wxPython 4.1 with wxWidgets 3.2.x, or wxPython 4.2.x with wxWidgets 3.1.5. The API exposed by wxPython 4.2.x differs from the 4.1.1 API, and none is a subset of the other.

That wxPython 4.1 corresponds to wxWidgets 3.1 and wxPython 4.2 to wxWidgets 3.2 is however something that is unclear and non-transparent. In this case the error that the underlying wxWidgets version is wrong is reported, which is unrelated to the wxPython version. But also a specific minimal minor version of 3.2.x is requested so depending on wxPython 4.2 would not suffice. Sure, we only ship one 3.2.X version in Tumbleweed that is recent enough, and 3.1.x in Leap which is too old and is built with different wxPython so for this specific case the wxPython version differs as well but it is not the case in general. For other libraries with more stable API the version range available with same bindings version might be even larger. -- You are receiving this mail because: You are on the CC list for the bug.