Okay I guessed that, so first, we (Vincent and me) are just going the normal route and make a working solution. So we're going to use the standard (in the best sense) python.org installers and we'll compile against them. I'll test the installers on my own 10.6 notebook and on the rather virgin 10.5 notebook of a colleague, with all the nose bells'n'whistles.
2010/10/14 Christopher Barker <chris.bar...@noaa.gov>: > 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... good. I guess the paver mentioned before does the rest of the work. We'll look into it. >> 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. Okay thanks. >> 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. I agree. >> 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. Just btw, I remember lots of issues with 2.7, but it may have been matplotlib. >> 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. Hm, not really, you can specify URLs where to download from, have you ever looked into the (10.6) PackageMaker? From my impression, it's a click-and-point package manager. (I.e., one downloads an executable for each download ...) >> 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. Ok, I see, it's just a matter of taste (not mine obviously). > 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. Everyone on the numpy list knows this never-ending story ... :-) At least in principle. > 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. Very clear. Thanks. >> 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... Nothing against using a 10.4 on Vincent's computer, the "concentrate on" was meant somehow else, but I don't remember. We're ready to start now, and will come back when we're stuck somehow. Friedrich >> 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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
