iraf.net

As a user, the two-distribution channel's for IRAF (iraf.net and noao's iraf site) seems confusing. Which has the "real" distribution? Are there differences between the latest releases? Where did the new package installer gets its source from? Etc.NOAO external packages http://iraf.noao.edu/extern.html
IRAF.NET external packages https://iraf.net/ftp/iraf/extern/For instance, I tried to install the ctio package using the new package installer in 2.15. The installer only successfully installs the sources, not the binaries (see below). I was unsure where the installer was getting the package from, so I downloaded both and compared them. I thought they would be the same but it appears that the iraf.net distribution of ctio is slightly newer (one bug fix and several changes in the mkpkg file). From the file differences and dates, it was clear that the installer was using a version from noao, not iraf.net. Just in general I think it is a tremendous advantage to users and developers to have a single distribution point. For example, in the external packages links above, there are packages that are in X but not in Y, and there are packages that are in Y but not in X, and there are packages that are in both but whose versions differ. This is difficult on users and may lead to bug reporting that makes life tough on the devs.Another topic: x11iraf is still being distributed under as "2.0beta" even though it feels like it has become the actual 2.0 release. Perhaps it's worth shedding the beta status, which may still be scaring away people from using it.In general, the number of changes in 2.15 are really impressive and a big step in the right direction. My experience is that my astronomer friends have been gravitating towards IDL. The 2.15 release may help that.One last comment in much broader scope, has there been any concept talk of what an IRAF 3.0 might entail? When the 2.x branch ends its life, what will become of IRAF?Jason*The output of the package installer can depend on the order in which packages were installed. For example, when I tried to install ctio as the first package, it warned me that it could only install the source. On a second attempt, when I tried to install stsdas first and then ctio, it just says "OK", and never warned about source-only.

[quote:0005074719]
As a user, the two-distribution channel's for IRAF (iraf.net and noao's iraf site) seems confusing. Which has the "real" distribution? Are there differences between the latest releases? Where did the new package installer gets its source from?[/quote:0005074719]The repository for the packager is ftp://iraf.noao.edu/iraf/v215/REPO, which is in fact different than the extern directories on either site. This is in part because the building of the tarballs is different by necessity, i.e. packages include binaries for a particular platform and the tarball is built at e.g. the "ctio" toplevel directory, and not the *contents* of the ctio directory as before. Where the extern directories were mostly consistent in how the packages were bundled, for the packager to work they must all be consistent. Also, because these bundles are meant to work with v2.15, some of the packages have the code changes necessary for 64-bit compilation.For the CTIO package I'll have to double check the build system to see which was used, there may indeed be a problem. I also realize things are confusing at the moment but they will be sorted out now that the IRAF release itself is out. Otherwise, note that binary repo files are still being built for all supported packages (in the end there will be more than 100 distribution files built for v215 so it takes some work), a binary distro for CTIO and other packages is coming shortly.In the long-term, iraf.noao.edu will always be the 'official' release point, however we will mirror the distributions on iraf.net so there will be no real difference (a recent server crash reminded me of this need) in the end. There are also plans to revise the iraf.noao.edu website shortly so it fits in better with the other NOAO web pages, and blends in with the iraf.net offering (e.g. announcements will be the same on both sites, RSS feeds from iraf.net will appear on iraf.noao.edu to lead users to the support forums). NOAO remains the official IRAF project source, iraf.net remains the official (or, at least, accepted) user-support site.So, look for changes and standardization soon, there just weren't enough people doing all this to get it done without holding up the v2.15 release even further.[quote:0005074719]
Another topic: x11iraf is still being distributed under as "2.0beta" even though it feels like it has become the actual 2.0 release. Perhaps it's worth shedding the beta status, which may still be scaring away people from using it. [/quote:0005074719]Despite being first released in March, some people are claiming v2.15 caught them by surprise because there was no name change to a 'beta' release. GMail was a 'beta' for years, but one lesson learned from 2.15 is that the name means something to some people. There are still some quirks in x11iraf I would like to fix but I don't expect to have time to address these, and you're right that making it an 'official' 2.0 release is probably long overdue. Still, if you've been waiting for a 24-bit XImtool for a decade, installing a 'beta' release is better than waiting for a name change.In the long-term we don't expect to do much more development on XImtool. With today's large and complex mosaics, the fundamental model of loading an entire image in memory to pan/zoom is just wrong (i.e. you shouldn't need +4GB of RAM to display the image). Likewise, there is little difference conceptually between managing many (i.e. tens to thousands) of files or image extensions representing a focal plane, and managing a collection of data from VO of an object taken from different sources or epochs. A tool that can better manage these data associations, local and remote sources, interface easily to databases and do logical things with catalogs, and do it all on your laptop is needed. There's little point in building this into XImtool so I'm planning to start a new project as soon as my schedule allows (this was supposed to start this Fall actually). We'll keep familiar and popular UI features, but under the hood, things will be much different to meet the needs of the next 10-20 years of use.
[quote:0005074719]
In general, the number of changes in 2.15 are really impressive and a big step in the right direction. My experience is that my astronomer friends have been gravitating towards IDL. The 2.15 release may help that. [/quote:0005074719]Strange, my impression is that people have been leaving IDL for Python. The whole "IRAF or IDL" question seems to be like "VI or Emacs", i.e. you use whichever you learned first until forced to use something else, or until something better comes along. I agree the v2.15 brings in some long-needed changes, I only wish we had the skilled resource needed to implement all the other changes we would like to make.
[quote:0005074719]
One last comment in much broader scope, has there been any concept talk of what an IRAF 3.0 might entail? When the 2.x branch ends its life, what will become of IRAF? [/quote:0005074719]Big question, but not one we haven't considered. We will, in fact, be putting together a long-term vision/roadmap document to address this, but that doesn't mean we'll get the resources to carry it out. Obviously, what can be done in 5 years with the current halftime effort is different than if we had a group of 3-5 people instead.Part of the answer depends on where you see strategic priorities: LSST will be all about catalog science, does that mean IRAF should have DB interfaces and catalog analysis as a focus? OTOH, hardware is moving towards multi-core CPUs and GPUs, does that mean we should focus on parallelism instead? Addressing either of these (or others) in the core interfaces then means changes to existing applications or new tasks, so where do we begin?Whatever the answer, the highest priority should be on preserving the science code in the system that has now become well-trusted, community-standard tools. Efforts to replace tasks with a new implementation are vulnerable to temptation to introduce new (buggy) features, and must then also prove their results to be as reliable as the task they replace. Likewise, I just don't see the institutional-will needed for a large development effort required to e.g. rewrite IRAF in Python (and then get that to be a trusted result). Today's astro-politics are still leaning toward project-specific development and not the community-wide systems of the past. My personal opinions about why a Sourceforge project or other IRAF-command interface to "replace IRAF" will fail are a topic for another discussion.Most likely, IRAF 3.0 will recast the existing tools into a more modern framework (the CL was always meant to be replaceable) for execution that allows them to work with other tools (e.g. even large systems like CASA or CIAO to do real multi-wavelength astronomy) easily. Some of this work is already being planned/studied as part of desktop integration work for the VAO, and would be in addition to the other minor projects continually being done. That said, I wouldn't worry about the 2.x tree ending anytime soon 8-)Cheers,
-Mike