Orsola from Oz has gotten in touch with AstroBetter and asked about the current state of Scisoft. For those not familiar, to me, Scisoft is a big installer that is the quick and dirty way of getting Python and IRAF installed on a Mac. I briefly looked into the current status of this package while updating the New Mac Setup Wiki but quickly gave up and me and some other folks at the AAS Hack Day agreed on this conclusion:
SciSoft is NOT recommended because it’s not modular and not routinely updated.
However, this is not very satisfying. Could y’all shed some light on the current state of SciSoft? It seems pretty non-trivial…
Also, is there anything that you can only install with Scisoft? In my experience, it causes way more trouble than it’s worth and that you should just bite the bullet and install everything you need individually rather than via this attempt at a catch-all script. Is there anything this is not true for?
Do you have an alternative to Scisoft OSX that works?
Note that Scisoft is an ESO product and is for Linux. Scisoft OSX is a privately distributed set of packages (inspired on Scisoft). I think that Scisoft if kept up to date quite well, which might not be the case for Scisoft OSX.
I find the STSCI_PYTHON package works well on OSX. It’s a one-click dmg package.
I use this and pip install everything else I need.
I have tried installing IRAF on Macs using the without Scisoft, with no luck. NOAO provides essentially no instructions. With Scisoft, it is quite simple.
Echoing Tom, I think the best way to get a functioning IRAF installation is with the STScI_Python package: http://www.stsci.edu/institute/software_hardware/pyraf/stsci_python/current/stsci-python-download
Scisoft was a great way of installing IRAF on a Mac for a while, but I’ve now given up on it. I have a six or seven step recipe that works just fine under lion and mountain lion. The assumption is that you are using csh or tcsh rather than bash, but it’s easily modified:
a) ftp iraf.noao.edu, log in as “anonymous”, your email as password. cd iraf/v216/PCIX, get iraf.macx.x86_64.tar.gz
b) sudo mkdir /iraf
sudo mkdir /iraf/iraf
sudo chmod a+w /iraf/iraf
mv [wherever you put it] iraf.macx.x86_64.tar.gz /iraf/iraf/.
un-tar it
setenv IRAFARCH macintel
setenv iraf /iraf/iraf/ [note the last “/”
sudo $iraf/unix/hlib/install
take the defaults (generally speaking)
There are some simple instructions for adding external packages that are in the readme file:
cd /iraf/iraf/extern
./configure
make stsdas
If you don’t need IRAF and just need an isolated python installation, I recommend using homebrew to manage unix packages and pip to manage python packages.
Clearly there’s a need for IRAF and pyraf to be supported in these package managers.
I agree with the sentiment! Scisoft packages are outdated and mess with dependencies if you want the newer packages installed. Having everything in “one-click” is nice, but not if that everything is outdated and doesn’t work with your data. I am one more voice speaking against Scisoft!
Re: IRAF – I bit the bullet and installed IRAF from NOAO (because I like the cl interface and have many, many scripts invoking it). It’s not that bad… I mean, for example this website gives a line per line instruction on how to do it on a Mac: http://www.iac.es/sieinvens/siepedia/pmwiki.php?n=HOWTOs.IrafMacOSX
It seems there is a big misunderstanding about Scisoft. There are TWO versions: Scisoft Linux, which is an official product maintained and distributed by ESO (this is the ORIGINAL VERSION); and Scisoft OSX, which is maintained PRIVATELY by ONE astronomer (originally developed by two people and currently beta tested by a few individuals) all on their own time and dime (including footing the bill for web hosting/domain name, hardware purchases such as computers and storage, etc), with no official support by any organization and made publicly available as a courtesy to the community. While Scisoft Linux may be the official installation package for some institutes, Scisoft OSX is not. No one is forcing any astronomer to use Scisoft OSX (it is not the official distribution for any institute) and users have always been welcome to help out with maintaing Scisoft OSX, provide feedback, add features, etc. If people are displeased with Scisoft Linux contact ESO (scihelp@eso.org), they have resources and people dedicated to supporting the LINUX distribution. But speaking out against or complaining about the OSX version seems rather a waste of energy. If you have problems with Scisoft OSX there are two logical/constructive paths to follow: 1) pitch in and help out! it could mean sending info about the issue (rather than demanding it be fixed), offering to help resolve the issue, posting the problem on the feedback part of the website and engaging in useful discussions with other users to hone in on the solution, etc; OR, find an alternative to use. But whining about it (or boycotting it) doesn’t help the person maintaining it, the people who use it, and it certainly won’t solve your problem. I doubt it matters to the person who maintains Scisoft OSX how many people use it, there’s no profit being made, no accolades attained, nor ego boosted by 5, 50, or 5000 people running the package.
Thanks Barry. I love scisoft. When I moved to lion I found that the $MACH changed from macintel to macosx. This sends the script located in /Applications/scisoft/Setup.csh into a branch of an if statement where it sets up directories that do not exist. Instead of correcting the script and running into more trouble I thought I would reinstall scisoft but found that the website is down. I was not aware of the development history of the bundle. I will try and patch the script and as soon as I run into more trouble I will see…. Best, Orsola
My preference tends to be to install scisoft (for IRAF/PyRAF) and then update python packages as needed. In the Scisoft OS X version, there is no reason why the python packages can’t simply be updated with pip. This includes matplotlib and even numpy (as well as astro specific packages like astropy, atpy, pywcs). This has been working for me for the past 5-6 years.
It has been ~3 years since I tried to install IRAF/PyRAF without scisoft on a new machine. I tried the NOAO instructions and the stsci_python package and neither worked for me. Some of this was perhaps 64-bit growing pains at the time.
Here at LCO, we ran into some incompatibilities and issues with Scisoft, and so we recently rolled out a new build of our Mac Mini observer workstations without it. I have documented our complete software install here:
http://www.lco.cl/Members/geychaner/Install_instructions.html
and all the custom scripts and applications used to perform the install are here:
http://www.lco.cl/Members/geychaner/Installers.dmg
If you have any suggestions, or find any bugs, please let me know!
The basic problem I think isn’t with scisoft but with IRAF. IRAF has an extremely, extremely old build system which makes it difficult/impossible to sync with new releases of software. The basic problem around 2000-2005 there was some interest in making IRAF easier to upgrade, but at the time IRAF had a lot of licensing issues which meant that people lost interest in fixing IRAF. With version 2.16, all of the licensing issues have been fixed, but there is no longer a group of people that are interested in fixing the build issues.
I’ve been looking into fixing up IRAF to generate an RPM that would make it possible to easily include it in the standard linux distributions, and this work would make it easier to generate a new Mac OSX build. I’m trying to gauge the amount of interest in this since it’s going to be a very big effort.
Check the v2.16 README file: Aside from a single-file tarball binary distribution for supported platforms, there was a lot of work already done on the build process. A “make sysgen” from the toplevel will build from source, and a “make latest” will apply any patched releases (and update the installed external packages as well). There’s no disagreement the “old method” of installing IRAF was too difficult, that’s why it was changed (but as with typing-flpr-three-times-to-fix-a-problem, the myth of an impossible IRAF install persists).
As long as I’m here, a +1 for Barry’s comment earlier.
Thanks for the information, that’s really useful!!!!
I’m trying to get 2.16 packaged right now, and i’ve found a number of bugs and difficulties in the build system, and it’s really useful to know that these are “fix the problems and send us the patch” problems rather than “give up completely” type oroblems. One thing that’s misleading is that there is a ton of pre-2.16 documentation that says “don’t even bother trying to build it from source” and it’s useful to know that this is out of date.
I’m trying to get an RPM package in place for Mageia, and that should be easily portable to other linux distributions.
Has anyone gotten IRAF uploaded to github? If not, I can start a tree and load up my patches.
FYI, I’ve got some of the IRAF executables built on linux. I should have the whole thing packaged in a week or so, at which point it will be available for the major linux distributions to pick up. I’ll also have things uploaded to github this week. One I have it uploaded, then whoever does the ESO scisoft IRAF builds can grab that and upload their changes.
Some observations:
1) someone has done a lot of good work cleaning up the build system. I’d like to know who it is and thank them, since a lot of the discussion about IRAF being impossible to build is outdated.
2) iraf.net isn’t registering new accounts.
3) the build system still has bugs so I wasn’t able to just type “make”. There are some places where that breaks down.
4) there is one showstopper. The build system still hard codes /iraf/iraf in a lot of places and this kills automated build farms
5) There is *lot* of work that can be done to improve iraf. Off the top of my head
5a) IRAF should use gfortran as the base compiler. Once you use gfortran you can pull in openMP, and that will greatly improve performance
5b) Several bits could be pythonized. In particular XC is just a compiler wrapper and it can be better reimplemented in python
> 1) someone has done a lot of good work cleaning up the build system. ….
>
> 2) iraf.net isn’t registering new accounts.
Both of those are my fault, you can send questions and bug reports directly to admin – at – iraf.net until the registrations are fixed.
> 4) there is one showstopper. The build system still hard codes /iraf/iraf in a lot of places and
> this kills automated build farms
We should take this offline, but please feel free to send these reports to me. There are still some bootstrapping issues that weren’t fully resolved, the intent is still that there’s a mode that doesn’t require an install to system directories.
> 5) There is *lot* of work that can be done to improve iraf. Off the top of my head
> 5a) IRAF should use gfortran as the base compiler. Once you use gfortran you can pull in
> openMP, and that will greatly improve performance
It isn’t as simple as that, trust me. However, there are plans for parallelization in the v2.17 release.
> 5b) Several bits could be pythonized. In particular XC is just a compiler wrapper and it can
> be better reimplemented in python
Also not as simple as that. Also defeats the purpose of ‘improving the system’ 😎
Thanks Mike.
I have a set of RPM spec files that I’m about to post on fedora-astronomy and send off to admin@iraf.net. I’ve gotten iraf to compile cleanly from source on Mageia and I’m in the process of getting it running. One issue is that most linux distributions now use bash so I’m having to do some cshrc->bash reverse engineering. The other issue is that I’m having to modify the build so that it uses host system files (i.e. the local curl and expat).
I’ve also uploaded a copy of IRAF onto github at
https://github.com/joequant/iraf
I’m working on my hacking on a side branch but the main branch contains a set of changes that should be uncontroversial (i.e. a lot of intermediate files got added to the system).