Mac Singularity

My Pyraf Installation Adventure

January 29th, 2007 by Marcos

So, I get a few search engine queries on pyraf that end up here – and occasionally searches of the site itself for pyraf. As you probably know, there is no pyraf installer here. The process of installing pyraf (or the larger stsci_python) is somewhat involved. But, I managed to do it today on my Mac Pro and I have lived to tell the tale. I’ll explain how I did it and where any problems popped up.

Ok, well let’s look at the requirements for stsci_python:

• IRAF (IRAF 2.13beta must be installed on MacOSX with Intel CPUs)
• TABLES/STSDAS – 3.6
• Tcl/Tk – v8.3 or higher

No problems here, installers are on this site for IRAF, TABLES, and STSDAS. Tcl/tk comes with OS X and it appears to be at version 8.3. What else does it need….

• Readline
• Python – v2.4 or higher (with readline and _tkinter modules enabled)
• Numeric – v24.2
• libf2c (Note: the package on our web site has a change that allows it to work on 64bit Linux platforms)
• Pmw 1.2
• Urwid -( optional)
• Ipython – (optional)

Ok, I needed some of these. Being a minimalist when it comes to installs, I ignored the Urwid and Ipython requirements. Python in Tiger is at 2.3, so that’s no good. I turned to fink for Readline, Python 2.4, Numeric, and Pmw. I installed Python 2.4 first, then the packages for it.

libf2c is included with iraf, and lives in /iraf/iraf/unix/bin.macosx or /iraf/iraf/unix/bin.macintel depending on your processor.

To make sure things are working, the stsci_python instructions say to try these commands:

%python
>>>import readline
>>>import Tkinter
>>>Tkinter._test()
>>>import Numeric
>>>import Pmw

and if there are no errors, you’re good. So, I tried them. Blamo – readline didn’t work. Oh, and python was curiously version 2.3. Hmm. It turns out fink installs python in /sw/bin which should have priority over the python at /usr/bin given the way that fink sets up its PATH variable. But, the python binary isn’t python it’s python2.4 so I had to create a symbolic link of python in /sw/bin and then typing python ran the fink python. Hooray. I learned later than a better approach is to change the symbolic link at /usr/bin/python to point at /sw/bin/python2.4.. This is because if you ever run an executable something_cool.py script, it may very well explicitly state the python path as /usr/bin.

All the above commands worked, but Tkinter._test() only will show a window if you run python from an xterm, xgterm, etc. or if you have manually set the DISPLAY variable in an OS X terminal. (Apple’s OS X Terminals do not set the DISPLAY variable which is why running X11 based programs from them usually fail. Simplest workaround – use an xterm or anything in which X11 appears as the active application – but not Terminal.)

Ok, so all now looked fine – I downloaded stsci_python, built numarray per their instructions, built stsci_python per their instructions (giving my f2c location as /iraf/iraf/unix/bin.macintel/) and pyraf was installed.

One extra thing I needed was scipy. That proved a pain because while I was able to compile numpy without any problems, scipy did not build giving some kind of g95 error. They had a binary for Tiger… but the download page explained that the binary installer would required Macpython or Activepython, neither of which I’d ever heard of before, and that the installer wouldn’t detect a fink build if python. Super. Indeed, it did not. So, not wanting to reinstall python, I used Pacifist to open the .pkg file and manually put the scipy folder in /sw/lib/python2.4/site-packages. This seems to be working, but I haven’t rigorously tested it yet.

Update The scipy trick very much did not work. I had to ultimately follow these instructions to compile scipy – the trick seemed to be that neither the fancy gcc 4.3 nor the Apple gcc 3.3 worked – it had to be gcc 4.02, and still I get 2 errors in the scipy.test(10). Confirming that I was using Apple’s gcc 4.02 required some trickery since I had installed gcc 4.3 from the MacOS X high performance computing site to get g95, and I don’t think scipy liked gcc 4.3

Anyway, it seems to be working now as well as I’m going to get it to…. the errors seem related to BLAS and check_dot. I don’t know what that means though.

Another update scipy woes continue. I either get the 2 errors in the test or I get malloc problems. And, the local package I’m trying to run which depends on scipy… that is producing odd “encountered invalid numeric results” problems. Which may or may not be scipy related but I think it is…

Yet another update – I’m told the failures in the scipy test don’t mean it’s not working … some failures are expected. The local pyraf based package however is very much not working, and in which package exactly the “invalid numeric result” is occurring is unknown at this time.

Related posts

• No related posts.

   Post in IRAF, Tips    3 Comments