[SOLVED] rant: wxPython

derguteweka · 01-31-2021, 07:22 AM

Moin,

What's causing the developers of wxPython to work like this?
Heck, some years ago, wxPython seems to be completely dead, the last version very old, still needing gstreamer-0.x., where everybody else was able also to use gstreamer-1.x

Now the complete opposite:
The current version of wxPython: 4.1.1 includes/downloads (wasn't there to watch) somehow some crippeled version of "wxWidgets-3.1.5".
But this is not yet available, it seems to be just just the master branch in git. So not really approved by the wxWidgets guys as 3.1.5.

Pls,Pls, dear wxPython developers: Just do it like most other sensible developers do: Don't include "special" versions of other dependencies into your source. Just take the available libraries in available versions, e.g. one marked as stable, one as bleeding-edge.
Preferably: Let your software be able to be linked against several Versions of the dependencies. Not just the latest-itzi-bitzy one.

Gruss
WK

TheRealGrogan · 02-02-2021, 04:51 PM

wxWidgets is a horrible pain in the ass. I detest it. The only thing I use it for nowadays is audacity, and I use their provided sources. Different versions and configurations of that don't necessarily work right with a given project, so there's a tendency to bundle it.

However, with wxPython you can attempt to use an existing wxWidgets installation. Here's the section in the README.rst from wxPython 4.1.1:

Code:

Building wxWidgets
------------------

Since build.py will, by default, build both wxWidgets and Phoenix you will
need the wxWidgets code as well. The source tarballs already include both
wxWidgets and the Phoenix source code, so if you are getting your copy of the
source code that way then you are all set. If you are fetching it from GitHub
you will need to do an additional step. The git repository is set up to bring
in the wxWidgets code as a git "submodule" so after cloning the Phoenix
repository, you can get the wxWidgets source with these commands::

  $ git submodule update --init --recursive

This will clone the wxWidgets repo into: ``Phoenix/ext/wxWidgets``. Once the
submodule is updated, the build script should be able to build wxWidgets.

If you would rather use an already built and installed wxWidgets then that is
possible as well by changing some options, see ``python build.py --help`` for
details. However be aware that doing so will require a wxWidgets that is
**very** close to the same age as the Phoenix code, at least for the
unreleased preview snapshots. In other words, the wxWidgets build should use
code from the wxWidgets source repository within a few days of when the
Phoenix code was checked out. Currently the master branch of Phoenix is
tracking the master branch of wxWidgets.

On the other hand, it is probably best to just let wxPython build and bundle
wxWidgets. The build tools will by default build wxWidgets in a way that
allows it to be bundled with the wxPython extension modules as part of the
wxPython package, meaning it can peacefully coexist with any wxWidgets
libraries you may already have installed. This bundling of the wx shared
libraries works on Windows, OSX and Linux, and probably any other unix-like
system using shared libraries based on the ELF standard. The libraries are
built in such a way that they are relocatable, meaning that they do not have
to be in a fixed location on the filesystem in order to be found by the
wxPython extension modules. This also means that you can do things like use
``pip`` to install a wxPython wheel in one or more virtual environments, move
the wx package to a versioned folder, or even move it into your own project
if desired, all without needing to rebuild the binaries. (Assuming that
compatible Pythons are being used in all cases of course.)

The build phase of the build.py script will copy the results of the wxWidgets
and Phoenix builds into the wx folder in the Phoenix source tree. This will
allow you to run and test Phoenix directly from the source tree without
installing it, if desired. You just need to set ``PYTHONPATH`` appropriately,
or you can use ``python setup.py develop`` or ``pip install -e .`` to install
an .egg-link file in your current Python site-packages folder that will point
to the folder where you built wxPython Phoenix. When you are finished testing
you can then use the install or one of the bdist commands like you normally
would for other Python packages.

derguteweka · 02-05-2021, 06:21 AM

Moin,

Quote:

Originally Posted by TheRealGrogan

wxWidgets is a horrible pain in the ass.

So far i didnt have any problems with wxWidgets itself, but i think i used it before wxPython just as dependency for some dependency of GNU Octave, maybe gnuplot, but i'm not sure about it.
wxPython is a dependency of KiCad, and seems to me, that it's the nastiest one.

Quote:

Originally Posted by TheRealGrogan

However, with wxPython you can attempt to use an existing wxWidgets installation.

Yea, but this is, where the sh*t already hit the fan.

When i write some "Hello World" in C, i do not use some git submodule to import the whole libc. Nobody would do something like this.
I just link the library to my code. Before, i include headerfiles shipped with the library into my code. There are good reasons to do it like this, and not put the whole libc into my Helloworld directory.
What are the reasons; why does wxPython do this in this awkward way?

Gruss
WK

jr_bob_dobbs · 03-14-2021, 09:10 AM

Anything involving Python makes me wince, knowing there's going to be problems. It's just spread like a cancer throughout the Linux ecosystem and has become unavoidable.