wxPython Phoenix states its licence three ways, and the file it names is not in the tree

Three licence statements and a licence file that is not in the tree

There are three statements about what this project is licensed under, and they do not line up. The package manifest declares the library licence version 2 or later, with a named exception added on top of it. The build script's own header, written by the author in 2010 and carrying a copyright range to 2020, calls it the wxWindows licence. The repository's own metadata records nothing, which usually means the hosting service could not identify a licence file. And the manifest points at a licence file by name in its licence files list, while the repository's top level listing does not contain a file of that name. For most users none of this matters, because installing from the package index gives you the terms the maintainers chose. For anyone redistributing, vendoring or auditing, the licence is currently something you have to obtain from the project rather than read from the repository.

The governance note names two maintainers and dates itself

The development section says who can merge: as of September 2024, two accounts, and one of them can also assign reviewers. That is a useful sentence to have, because a project with a two person merge gate should say so, and this one does. The problem is the date attached to it, which is now two years behind the last commit in the repository. Nothing in the sentence marks it as a snapshot, so a reader arriving in 2026 takes it as current and concludes that two people can merge, when the truth might be one, or three, or that the arrangement has changed entirely. It is a small example of how a useful governance statement decays: nobody has to edit it wrong, they only have to not edit it. Projects that write these down should date them the way changelogs are dated.

Two build scripts delegate to each other in both directions

The build story is split across two scripts with a relationship the readme spells out carefully. One script is the primary interface, exposing commands for the individual code generation steps and the builds, and it is what the readme tells anyone working from a checkout to use. The other is the conventional setuptools script, and it assumes the code generation has already happened, which makes it suitable for building from a released source archive or when a package manager invokes it. The delegation is circular by design and both directions are stated: the setuptools script hands the real work to the primary script, and the primary script hands control back to the setuptools script when pip is driving the build or when a wheel is being produced. It is a slightly confusing arrangement to learn, and it is documented well enough that a newcomer will not waste an afternoon on it.

The toolkit arrives as a submodule that has to match your checkout

The build compiles the C++ toolkit and the bindings in one pass by default, so a checkout is not enough on its own. The toolkit comes in as a git submodule and has to be initialised recursively, which puts it inside the repository's extension directory where the build expects to find it:

git submodule update --init --recursive

Using a copy of the toolkit you already have is supported through an option, and the readme is unusually blunt about the constraint: it has to be very close in age to the Phoenix code, within days for the unreleased preview snapshots, because the two projects track each other's branches. Even then one more submodule is needed for the build to succeed, so the shortcut saves compiling the toolkit and not the dependency. The default is the right one, and the readme says so at the end of the section.

The bundled toolkit is deliberately built relocatable

The default build bundles the toolkit's shared libraries with the extension modules instead of linking against whatever is installed on the machine, and that choice has a specific purpose stated on the page: it lets the bundled copy coexist with any other copy of the toolkit you already have. The libraries are then built so they can be found without being in a fixed location on disk. That is what makes several ordinary things possible. A wheel can be installed into more than one virtual environment. The package directory can be moved to a versioned folder, or moved into your own project tree, and the extension modules will still find their libraries. So the whole thing is relocatable by design rather than by accident, which is the property that makes a package like this pleasant to distribute even though it is enormous.

Snapshot releases carry a revision count and a commit hash

The release list does not contain version numbers, it contains snapshot identifiers. The three most recent are all labelled as snapshot builds, and each version string has the form of a release number followed by a letter, a revision count, a plus sign and a short commit hash. That is a pre-release identifying exactly which tree it was produced from, which is the right thing to do for this project: a build of a generated binding is only reproducible against a known toolkit revision, and the embedded hash is what lets you check that. It also means the version is not a clean semantic version, so anything that assumes one, a lock file comparison or a release notes index, has to cope with a local version segment after the patch number. The newest snapshot was published after the last commit in the repository, so it describes a tree that has since moved.

The demo directory still ships examples for ActiveX controls

The demonstration scripts are a catalogue of what the toolkit has wrapped, and reading their names is the fastest way to see how old some of that surface is. There are examples for an embedded Acrobat control, an Internet Explorer control, a Flash window, an IE HTML window and a PDF window, all of them built on ActiveX, plus examples for the notebook, the docking frame manager, the multiple document interface, animations, custom art providers, private fonts, and the Cairo drawing bindings. The ActiveX examples are the ones worth noticing: they target a Windows component technology that current Windows versions no longer ship, so those five demos cannot run anywhere today. They are harmless as source, they are a fair description of the toolkit's history, and they are a reminder that a wrapper library's surface outlives the platforms it wraps.

Editorial conclusion

Use Phoenix if you want a native desktop interface from Python and you are willing to write against a generated API rather than a hand maintained one, because everything here flows from generating the wrappers and building the toolkit alongside them. Three things to know before you start. Read the licence records rather than assuming one, since the manifest and the build script name different terms and the file both point at is not in the tree. Use the documented build script rather than the setuptools one if you are working from a checkout, because one assumes the code generation already happened. And pin your toolkit version to your checkout's age, since the project states that a system toolkit only works if it is within days of your own copy.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wxWidgets/Phoenix on GitHub