I need an up-to-date version of wxPython in PyPI as a dependency for my project. I also need this version to have couple of bug fixes and features that I have submitted but are still in the PR state but not yet merged in.
I created this because I need it. But I am offering it here as an alternative to the nightly snapshot builds for those that need a bleeding edge wxPython and prefer or need the convenience of PyPI at the expense of not being an official release.
I am uploading wheels for MSW 64 and 32 and Mac, but only for Python 3.11 and 3.12 --This is a bleeding edge release after all–. I plan to release manylinux wheels too, but so far I have failed to create truly portable ones as discussed at Linux wheels with manylinux2010 - #22 by jmoraleda
I do not intend wxPythonMeticy to diverge from the official wxPython repo. In fact quite the opposite, I intend to rebase to master frequently and once all my PR’s are merged in, it will just be a mirror.
Hello Humberto. I intend to maintain wxPythonMeticy in PyPI for the foreseeable future. I do not intend it to diverge from the official wxPython. Please see the original message on this topic for more details of what this is.
Hello,
I’ve released wxPythonMeticy 34 on PyPI from my GitHub fork to provide an up-to-date version with specific bug fixes and features I’ve submitted. It’s tailored for those needing bleeding-edge wxPython via PyPI, offering MSW 64-bit and 32-bit, Mac, and planned manylinux wheels for Python 3.11 and 3.12. wxPythonMeticy aims to closely track the official wxPython repository, with frequent rebasing until all PRs are merged.
I have published a new version of wxPythonMeticy to pypi.
But with the release two weeks ago of an updated official wxPython I would suggest installing that one instead unless you need the handful of bug-fixes and features committed to the official wxPython master branch since the official release.
Incidentally some of those bug-fixes/features committed since the release were part of the earlier wxPythonMeticy releases. Currently all features and bug fixes in wxPythonMeticy have been merged into the official wxPython master branch, so currently wxPythonMeticy is just a mirror of the latest official wxPython master branch with no additional bug fixes or features.
I intend to keep publishing regular updates of wxPythonMeticy to pypi tracking the official wxPython master branch as described in the original post.
I have published a new version of wxPythonMeticy to pypi. Feel free to use it if you need any of the bug fixes and features committed to the repo since the last official wxPython was published in September.
I have published a new version of wxPythonMeticy to pypi. It is identical to the the current tip of the official master branch, including using wxWidgets 3.3, for the first time. Feel free to use if you want to test your application against 3.3 before the next official release switches to it.
What’s the difference?
Does it install in …Lib\site-packages\wx?
My app is embedded, any difference with compilers?
wxPython based on 3.2 has a serious bug that causes my app to throw an exception on shutdown, its fixed since 3.3 I am weighing my options on porting to wxPythonMeticy to get this resolved.
What ae the potential conflicts?
What’s you plan for maintenance going forward? I would target a fixed version I.e. (2026.7.18.1), so I would need it to be on pypi for some time.
wxPythonMeticy is drop-in compatible with wxPython. It installs into the same site-packages/wx location, so you can install either package from PyPI and your application should work the same with either one. Because they install to the same location, however, installing or uninstalling one will overwrite the other.
As I explained above, I originally created wxPythonMeticy because I had submitted several bug-fix PRs to wxPython that I needed for my application before they had been merged and included in an official release. At this point, wxPythonMeticy tracks the current wxPythonmaster branch; the primary difference is that the package has been renamed so I can publish it on PyPI.
There are no additional modifications beyond the package rename. In practice, using wxPythonMeticy is equivalent to building the current wxPythonmaster branch yourself. You can verify this by comparing it with my GitHub fork.
I update my application to each new wxPythonMeticy release as soon as I publish it, and I keep previous releases on PyPI for at least a year. My expectation is that, well before then, wxPython will have made an official release incorporating these changes, at which point you can switch back to the official package if you prefer.
Thanks for the info, I’ll test it in a branch. My issue is wxPython calls wxXmlInitResourceModule() [wxWidgets issue #26039] which apparently was 25 year old code that needed fixing. My app is for AutoCAD, BricsCAD , ZwCAD, and GStarCAD
GStarCAD throws an access violation at wxEntryCleanup(), there’s no public release for this fix in wxPython, except for wxPythonMeticy.
I can’t wait any longer, I guess my best option is to publish a fork of wxPython.
wxPythonMeticy might be a great solution, I just don’t want to have to tell users to swap out wxPython installs at a later date, some of the installs are deployed throughout large CAD firms
