[AstroPy] Co-ordinating Python astronomy libraries?
Tue Jul 6 13:36:22 CDT 2010
Unlike several people who have replied so far, I have not been involved in general purpose astronomy libraries, but rather a few small packages, including:
- APLpy (FITS image plotting built on matplotlib) at http://aplpy.sourceforge.net (co-developed with Eli Bressert)
- ATpy (Seamless multi-format table handler) at http://atpy.sourceforge.net (also co-developed with Eli Bressert)
- IDLSave (To read IDL save files into python) at http://idlsave.sourceforge.net
- python-montage (Montage wrapper) at http://python-montage.sourceforgenet
The main reason for keeping these separate rather than group them into a single package was that each of these packages accomplishes a well-defined task, and we were not prepared to develop all the other tools needed in a general-purpose library. However, I think that from a user point of view, it would be nice to have something more unified.
The main point I want to make is that we need to distinguish between merging all development into a single repository, and bundling packages. There are cases where merging the development of packages does not make sense. For example, in the case of IDLSave, the module was originally developed for the astronomy community, but in fact can be used by any scientist that uses IDL. By developing it as part of a general astronomy libraries makes it less likely that non-astronomers will find it and use it. Another example is Tom Aldcroft's asciitable module (http://cxc.harvard.edu/contrib/asciitable/). This was developed to read in ASCII tables, but was not actually designed in an astronomy specific ways, since ASCII tables are of course not limited to astronomy. In the case of such a package, developing it as part of a general astronomy library would be detrimental, but bundling it as part of a general package might be desirable.
So here is what I personally see as the ideal (hierarchical) setup:
1. A core library of essential routines, which handle for example FITS I/O, VO tools, WCS, coordinate transformations, etc. These could be held on a common development server. This would be a kind of 'numpy' or 'scipy' for astronomy, e.g. 'astropy' or 'astrocore'. Documentation for these would be merged and unified.
2. An astronomy 'bundle' which would include these essential routines, as well as extra astronomy packages (e.g. asciitable, IDLSave, ATpy, etc.). This bundle could be installable on top of the system python, or the enthought python distribution, e.g. 'astrolab'. Documentation for the extra packages would be left to the developers, but could be required to be of a consistent style (e.g. Sphinx) for inclusion in the bundle.
3. An 'all-in-one' package that would also include a full Python distribution, with numpy, scipy, matplotlib, etc - essentially an alternative to EPD for astronomy, e.g. 'APD (Astronomy Python Distribution)'. It could even come with a custom ipython prompt with all packges pre-loaded. All dependencies would be included.
This would then cater to the different levels of python users in Astronomy. One quick note is that if we follow this or a similar model of bundling some packages without merging development repositories, is that developers of small packages will need to be more careful what license they release their code under, to ensure they can be bundled and re-released (but this should be trivial).
On Jun 30, 2010, at 5:48 PM, James Turner wrote:
> Dear Python users in astronomy,
> At SciPy 2009, I arranged an astronomy BoF where we discussed the
> fact that there are now a number of astronomy libraries for Python
> floating around and maybe it would be good to collect more code into
> a single place. People seemed receptive to this idea and weren't sure
> why it hasn't already happened, given that there has been an Astrolib
> page at SciPy for some years now, with an associated SVN repository:
> After the meeting last August, I was supposed to contact the mailing
> list and some library authors I had talked to previously, to discuss
> this further. My apologies for taking 10 months to do that! I did
> draft an email the day after the BoF, but then we ran into a hurdle
> with setting up new committers to the AstroLib repository (which has
> taken a lot longer than expected to resolve), so it seemed a bad
> time to suggest that new people start using it.
> To discuss these issues further, we'd like to encourage everyone to
> sign up for the AstroPy mailing list if you are not already on it.
> The traffic is just a few messages per month.
> We (the 2009 BoF group) would also like to hear on the list about
> why people have decided to host their own astronomy library (eg. not
> being aware of the one at SciPy). Are you interested in contributing
> to Astrolib? Do you have any other comments or concerns about
> co-ordinating tools? Our motivation is to make libraries easy to
> find and install, allow sharing code easily, help rationalize
> available functionality and fill in what's missing. A standard
> astronomy library with a single set of documentation should be more
> coherent and easier to maintain. The idea is not to limit authors'
> flexibility of take ownership of their code -- the sub-packages
> can still be maintained by different people.
> If you're at SciPy this week, Perry Greenfield and I would be happy
> to talk to you. If you would like to add your existing library to
> Astrolib, please contact Perry Greenfield or Mark Sienkiewicz at
> STScI for access (contact details at http://scipy.org/AstroLib).
> Note that the repository is being moved to a new server this week,
> after which the URLs will be updated at scipy.org.
> James Turner (Gemini).
> Bcc: various library authors
> AstroPy mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the AstroPy