[Pythonmac-SIG] Python development on OSX
Hello everyone, I've been doing Python development on Windows for several years, and now I will also be trying this on OSX. After getting my Macbook Pro, I've updated the os/software, then tried updating to Python 2.7. No knowing there are so many places to get the core Python installer for OSX, a friend had suggested that I install the Macports installer for 2.7 That installed fine, and I ran the command line that put that as the default Python to execute. I also use wxPython and want to continue developing wx apps on the Mac. When I tried running the installer for wx, a message was displayed indicating the postflight script had problems (I do have some info about the specifics of that problem somewhere, but it's not handy at the moment). So-my initial questions are... 1. Why are there so many "variations" of the Python installer for the Mac? (I'm not referring to 32-bit vs 64-bit architectures, although that does complicate things quite a bit). For example, there is the OSX installer at Python.org, then there are the Macports python variations, and I recently read about something called Macpython. How does one know which o to use? Thanks ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python development on OSX
Thanks Dan Fink? Which one is that? On Sun, Jan 16, 2011 at 7:30 PM, Daniel O'Donovan wrote: > Hi Tony, > > >1. Why are there so many "variations" of the Python installer for the > Mac? > > > I think you'll find that the biggest difference between MacPorts python > (and fink python) and most other builds (python.org for example), is that > MacPorts uses X11 rather than Aqua (Apple's native window manager) and are > not built as Apple 'Frameworks' - but rather regular shared libraries (more > like with linux). > > Using fink and MacPorts help integration with many linux type apps > (particularly helpful for scientific programming) whilst the native, > Framework builds are better for native looking Macintosh apps - and the > Apple bundled python is obviously native. > > This is a simple summary, and there are 101 more differences between all > the builds - but I think the first decision you'll want to make is whether > to go the Linux route, or go 'native' ;-) > > hth, > > Dan > > Daniel O'Donovan > [email protected] > > > > ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python development on OSX
>>Using fink and MacPorts help integration with many linux type apps > (particularly helpful for scientific programming) whilst the native, > Framework builds are better >>for native looking Macintosh apps - and the > Apple bundled python is obviously native. > > >>This is a simple summary, and there are 101 more differences between all > the builds - but I think the first decision you'll want to make is whether > to go the Linux >>route, or go 'native' ;-) > Since I don't have any other specific needs at the moment other than developing wxPython apps, I think I'd better go native, since wx attempts to make the widgets look native. Well, that's a good start, but I probably need to uninstall Macports, so I can get wxPython installed to a working state. And- I want to update the default python that came om my macbook pro to 2.7. Should I do install that from Python.org? ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python development on OSX
In article , Tony Cappellini wrote: > On Sun, Jan 16, 2011 at 7:30 PM, Daniel O'Donovan > wrote: > > I think you'll find that the biggest difference between MacPorts python > > (and fink python) and most other builds (python.org for example), is that > > MacPorts uses X11 rather than Aqua (Apple's native window manager) and are > > not built as Apple 'Frameworks' - but rather regular shared libraries (more > > like with linux). Actually, while Fink uses a Unix-style shared library build, most other distributors including MacPorts, the Apple-supplied Pythons in OS X, and the ActiveState Pythons, use an OS X framework build based on the python.org builds. The Tk on MacPorts is built as an X11 version by default but there is an Aqua port variant at well. Unfortunately, the Aqua variant is broken on OS X 10.6 but there is hope that it will get unbroken now that ActiveState has started packaging a reliable version of the patched Cocoa-based Tk 8.5 which works in both 32- and 64-bit modes. -- Ned Deily, [email protected] ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python development on OSX
In article , >1. Why are there so many "variations" of the Python installer for the > Mac? (I'm not referring to 32-bit vs 64-bit architectures, although that > does complicate things quite a bit). > > For example, there is the OSX installer at Python.org, then there are the > Macports python variations, and I recently read about something called > Macpython. > > How does one know which o to use? You left out a few! Why are there so many? History, varying needs, release schedules, because it's a fun thing to do - those are some of the reasons. Here is my take on it. Since at least Mac OS X 10.3 (7+ years ago), Apple has been including one or more versions of Python as part of OS X and over the years they've added more and more third-party Python packages and a few of their own Python add-ons. For many people's needs, the Apple versions are sufficient. On the other hand, like many operating system distributors, Apple tends to be very conservative about which versions it includes in major OS X releases, which tend to come out every two years or so, and they usually only supply security and some bug fixes in between major releases. For example, the current OS X release, 10.6.6, has Python 2.6.1 (released 2008-12) and 2.5.4 built in. At the moment, Python 2.7.1 and Python 3.1.3 are current. So, people looking for the latest and greatest Python releases usually have to look elsewhere. Back in the old days prior to Mac OS X, there was a project to make Python available on its predecessor, Mac OS 9 (and earlier). That was known as MacPython and, in the early releases of Mac OS X, it continued to make releases for OS X. At some point, the MacPython project was merged into the standard Python Software Foundation (PSF or python.org) development and release process and installers for OS X begin being supplied as part of "official" releases of Python, rather than from a separate MacPython project. That's where we are today although there are still vestigial references to MacPython online. One of the interesting characteristics of Mac OS X is that it combines technology from different origins and so it presents different faces to different kinds of users. A lot of stuff comes from its NeXT operating system heritage, a somewhat non-traditional Unix. When Apple decided to use it as the basis for Mac OS X, features were added to make the transition easier for users of traditional Mac OS. And more and more vanilla open-source products and features from modern Unix-y systems (like the BSDs and Linux) were incorporated. That shows up in Python in a few ways, including two rather different ways of installing Python on OS X: a traditional shared library approach as is used on nearly all other Unix-style systems, and a unique-to-OSX "framework" install which is based on NeXT practices. Most distributors of OS X Pythons use the latter but not all. Another feature of OS X, rarely seen elsewhere, is the ability to have executable code for multiple architectures "glued" together into one file, a so-called universal file. That allows Apple to distribute one set of executable files and libraries that can support current and previous architectures. That was used to ease the big transition from PPC to Intel CPUs and, more recently, from 32-bit Intel to 64-bit Intel. It allows for a lot of flexibility and backwards compatibility but at the cost of added complexity for third-party languages like Python. So some of the reasons for different Python installers have been because of what architectures are supported and differing approaches to backwards compatibility (like how many OS X releases to support with one version). Another reason: while Apple supplies a lot of open source software as part of OS X, it doesn't supply everything. One common reason is because of licensing issues (avoiding GPL libraries, for example). Also, Apple does not supply a package manager for its software, like those developed over the years for other open source systems. There have been at least three projects that have evolved to address that: Fink which provides many of the Debian/Ubuntu packages for OS X (without the Linux kernel of course); MacPorts (previously known as DarwinPorts) which provides the FreeBSD package ports; and, more recently, HomeBrew which has its own way of managing packages. All three provide Python ports and the associated infrastructure. And that can be very useful on Mac OS X when you want to install and run Python packages that depend on third-party libraries not included with OS X. Classic examples of those are the Python Imaging Library (PIL) and MySQLdb. Both require libs not included in OS X. You can build everything yourself but, for everything to work, you need to make sure that all the pieces are compatible, that is, built with compatible archs and deployment targets. A good package manager, like MacPorts or Fink, will eliminate t
