On Wed, Mar 14, 2012 at 9:17 AM, Paul Moore <p.f.mo...@gmail.com> wrote: >> It's reasonable to argue that this is only a windows problem.
no -- it's a Mac OS-X problem, too. Indeed, a harder one, due to: A) The Mac platform now has 4! architectures: PPC, PPC64, x86, intel64. Granted, PPC is almost dead, PPC64 never saw much use, and even 32 bit x86 is on the way out. Never the less -- at least 32 and 64bit intel are going to be around for a while. B) OS-X support fat binaries, and the pyton.org binaries have been built that way for ages. C) OS-X moves forward, fast -- it's gets pretty ticky to build binaries that run on older versions than the one you are building on (it can be done, to a point, but it's hard to get right) >> - Consumers of applications should get application installers, >> possibly with embedded copies of Python. sure -- but people developers need to build those... > >From my experience, that happens more often on Windows than elsewhere > (py2exe/cx_Freeze). I didn't think Unix people did that. not as much, but Mac developers do. >> - Consumers of libraries are developers who should be able >> to install development tools. In theory, yes, but: 1) there are folks that want to do a little python that don't have any experience or interest in the whole C building thing -- and to get the compiler on the Mac, you need to register with Mac Developer connection, then download a MASSIVE binary -- it's not a trivial lift. 2) as a stated above, building binaries of packages that you can re-distribute to other systems (py2app) is tricky -- even more so when you need compiled dependencies (libjpeg, libfreetype, that sort of thing) So the short version is -- binary packages are important on the Mac. Which brings up another point: Universal binaries (i.e. more than one architecture in one binary) have never been properly supported by binary eggs/setuptools. I think it may be as simple as the naming convention -- the binary would be named according to the machine it was built on (i.e. PPC) but when you tried to install in on another machine, setuptools would look for one called, i.e. "x86" and not find it. There may be some other issues, too, but in any case, we need to make sure the naming convention handles the multi-architecture case as well. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig