On 10/13/10 12:48 PM, Friedrich Romstedt wrote: > 2010/10/13 Christopher Barker<chris.bar...@noaa.gov>: >> Ideally, I think the Mac numpy binaries should match the python.org >> python binaries: >> >> Python 2.5: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >> Python 2.6: 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >> Python 2.7 32-bit PPC/i386 for Mac OS X 10.3.9 through 10.6 >> Python 2.7 PPC/i386/x86-64 for Mac OS X 10.5 or later >> Python 3 ??? (similar I think)
> We have to decide about how to install Python on the machines. It > aren't VMs, as one cannot virtualise workstation Mac OS X using > acceptable tools. there is no problem with multiple python versions being installed at once on one machine -- only one is "Current", but all you need to do to build for others is specify: python2.5 setup.py build python2.6 setup.py build etc... > The most straightforward way would be to just install the python.org > binaries available. Note that Python 2.5 *must* be compiled on Mac, > there is no binary on python.org. there is one for 2.5.4, but not for 2.5.5 -- in fact, it looks like there are NO binaries for 2.5.5 on python.org. I don't see any reason to worry about it thought, 2.5.4 should be fine -- that's what people are likely to be running anyway. > I would like to discuss the feasibility of compiling numpy against a > host-built Python built from the sources from python.org. What's the point? Anyone that builds their own python can build their own numpy, the point of the binaries is to target the less experienced user. > In this > case I would compile including the x86_64 arch, if it is available on > 10.5 at all? Could both users of a self-built Python (e.g. 2.6 on > 10.6, this would be my case), use this precompiled numpy then, as well > as users using the python.org binaries? It would enable users to use > x86_64 arch without self-compiling. I suppose so, but only if you distribute the python binary too -- I"d say if you want 64bit, use 2.7. I think Ronald made a pretty good choice with the way he set up the binaries on python.org. > Is there a check if the python.org installer was run and is registered > in the computer's package database? I have not idea how to do that -- but OS_X's "package manager" is really pretty lame -- it's not really a package manager, really just an installer. > Ralf, what is the advantage of hard-coding the destination directory > over running a setup.py script as postflight in the package installer? > (I understood that background-compilation is really not such a bright > idea.) The hidden setup.py would be compatible with all installation > locations of the user's Python. if you are going to do that, you might as well have them download a tarball and "setup.py install", or use a egg. The goal of the binaries is to be, well, binary, and be an easy point&click install. If you use macport or fink for your python, use them for numpy, if you build your own python, build your own numpy. In the MacPython community, we are trying (though largely failing!) to be able to recommend one simple way to do python on the Mac: the python.org installers, and binary packages built for them. There are two fairly distinct user groups for OS-X: The unix-y folks that use the command line compile stuff for themselves, etc, and the Mac folks that excepct point+click installers -- the point of the binaries is to target the second group. > I would like to concentrate first on the 10.5 machine of Vincent. but can we build on 10.5 and have it work on 10.4? In theory yes, but then in theory we can build on 10.6, too... > 1) Installation scheme of the different Pythons on the packager > machine (binary or host-compiled) see above -- host compiled really isn't the point -- there are already ways to do that (by the way, not every python user even has the compiler installed) > 2) Layout of the installer (hardcoded or hidden setup.py) I don't know if you can embed a setup.py in a mpkg, but I wouldn't bother, with all the binary compatibility issues, this will be an installer designed for a particular python install, anyway. -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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
