[SciPy-User] [AstroPy] Co-ordinating Python astronomy libraries?

[James Turner]

Hi Thomas,

I think this seems a good idea, even if it only solves part of the
problem. Astrokits (or just scikits?) could be a good place for code
to go whilst it's maturing, or for other reasons, with a low barrier
to entry. We could encourage authors to follow the same standards/
guidelines as the core library, without enforcing them.

A couple of limitations spring to mind. First, a proliferation of
astrokits with overlapping functionality could perpetuate duplication
and incoherence. As Perry said, there's no harm in doing something a
couple of ways to see which is best, but if there are 5 different
wrappers for WCSLIB, that's just confusing and makes it hard to focus
on quality. WCS is not the best example, since you proposed putting
that in the core, but in general this seems like something to keep in
mind and it isn't solved just by associating different libraries.

My second immediate concern would be distribution -- installing lots
of astrokits could be a bigger problem for end users than a single
library. Of course that could be solved by including most of the
astrokits in our Gemini/STScI Python distribution once it's available,
but these are early days and I don't think we're ready to promise the
whole astronomy/science community a solution to its installation
problems. Maybe others (eg. scisoft) would also pick them up though.

Nevertheless, I think astrokits can only be better than lots of
totally uncoordinated libraries and they could be a good path to
accepting code into the core and/or encouraging contributions that
might not happen otherwise. I think I'd back this proposal, unless
others have objections I haven't considered yet -- but I'm not
speaking for Perry's group, which ultimately manages Astrolib.

Cheers,

James.


> Hi all,
> 
> After reading all the replies, I have the following suggestion to make.
> 
> The model scipy follows is to have a 'core' scipy package, and 'scikit' packages which share a common namespace, and which are meant as addons to the scipy package, but have not yet (or might never) make it to the main scipy package:
> 
> http://www.scipy.org/scipy/scikits/
> 
> "Scipy Toolkits are independent and seperately installable projects hosted under a common namespace. Packages that are distributed in this way are here (instead of in monolithic scipy) for at least one of three general reasons. Each of these reasons use the same high-level namespace (scikits)."
> 
> I think we can use this model, and that the following approach can be used here, namely:
> 
> - start with a very basic 'astropy' package, with e.g. support for FITS/WCS
> - agree to coordinate astronomy packages with a common namespace (e.g. 'astrokit', so for example, APLpy would become astrokit.aplpy). This can help us manage the namespace (as suggested in Joe Harrington's email)
> - as astrokit modules mature, they can (if the authors are willing) be merged into the main 'astropy' package, once they have met a number of conditions, including e.g. unit tests, sphinx documentation, limited dependencies (e.g. numpy/scipy/matplotlib, and any package in the 'astropy' package), and compatible license.
> 
> The advantage of this model is that this encourages the growth from the bottom up of a core astronomy package, which is manageable, as well as the independent development of other packages. It also means that the core package will be quite stable, because it will only accrete 'astrokit' modules as they become stable and mature. At the same time, it encourages developers to make their own innovative astrokit, but without commitment from the maintainers of the core package to accrete it in future.
> 
> In passing, this also leaves the possibility for those who want to develop meta-pacakges of astrokit modules. Also, it will make it easier for those who want to build fully fledged astronomy python distributions.
> 
> There have been many ideas passed around in the mailing list, but I think that some are maybe too ambitious. I do think that the idea suggested above is much more manageable. The concrete steps would be:
> 
> - setup a central repository for the core packages, as well as astrokit pacakges (although we should leave the option for people to develop astrokit packages outside this repository too, and rely on trust and communication to avoid namespace clashes)
> - start a core package with e.g. FITS and WCS support (e.g. pyfits + pywcs)
> - set up a list of 'registered' astrokit names to avoid conflict.
> - set up a list of recommendations and requirements for astrokit pacakges
> - encourage developers of existing packages to use this namespace and follow the guidelines. This would be very little work in some cases, which is why I think it could work.
> 
> Sharing a namespace is (I think) the first step to showing that we are willing to work on something coherent, and users would only see two top-level namespaces - astropy and astrokit, which would be a great improvement over the current situation where it is not immediately obvious which packages are astronomy related.
> 
> Comments/suggestions/criticism welcome!
> 
> Cheers,
> 
> Tom