We’ve recently made the decision to start applying resources to generating x86_64 OS X builds of EPD. Because of limited resources, this means we’re officially dropping PPC support in EPD. It also means that it may take us months to get things released for the x86_64 (also known as amd64) architecture.
As an example of some of the issues we’ll face, we’ll need to decide how to handle the GUI backend situation. You see, the wxWidgets project hasn’t yet released 64-bit build support for OS X’s Cocoa framework, and the Carbon framework isn’t 64-bit, so we’re stuck either starting with a “server” / console build of EPD, shipping on an unreleased version of wxWidgets, delaying the release while we help finalize x86_64 Cocoa builds of wxWidgets and wxPython, or switching to a different backend like Qt.
While Qt and the PyQt (Python bindings for Qt) seems like a no-brainer technology-wise, the license situation is a hurdle for us to overcome. We’ve tried hard, but haven’t always succeeded, to avoid GPL licensed projects in EPD in order to make it more palatable to commercial users, like even our own consulting projects. And, yes, Qt itself recently came out with an LGPL license option that would suit EPD’s needs, but PyQt isn’t similarly licensed (yet). So now we have to decide whether such a core capability (the only GUI backend of OS X x86_64) would be acceptable to be GPL licensed.
If any one has any thoughts or suggestions on how to resolve this issue, please don’t hesitate to let us know!
By the way, regarding the PPC situation, we have effectively already started to drop PPC support with the EPD Py25 v4.3.0 release. We made a good faith effort to build in the PPC support but simply didn’t do significant testing of the results. In the end, it turns out that at least one core module, SciPy, ended up with binaries that don’t fully support PPC. Sorry, but we do not plan to issue fixes for this.
If you’re a PPC user, the last working version of EPD for PPC was EPD Py25 v4.2.30201.