[AstroPy] AstroPy Digest, Vol 58, Issue 16
jturner at gemini.edu
Tue Jun 14 14:42:49 EDT 2011
Thanks for the candid remarks. It seems like a good time for Perry
to comment :-). I do think the solution needs community buy-in, so
this kind of discussion is important.
I believe the AstroPy list belongs to Paul Barrett and I'd be
interested to know what he thinks about naming stuff after it.
PS. Regarding the Astrolib repository, I know there have been some
practical reasons for moving it a couple of times and now it is
hosted on a paid Sourceforge-like site (not sure it does git). I
don't know whether that counts as a neutral location.
On 14/06/11 14:20, Thomas Robitaille wrote:
>> I believe that was basically the idea of Astrolib -- a place to
>> collect key modules that others in the community would use. Do you
>> prefer the AstroPy name, or a different organization (or management)
>> from Astrolib? Or maybe you're suggesting something new to avoid
>> endorsing one existing effort over another (since there are other
>> libraries doing similar things now)? I'm just wondering what needs
>> doing differently. I know documentation was an issue last year --
>> STScI did set up a Sphinx server, but its presentation is currently
>> a bit rough around the edges. I certainly don't want to stall any
>> discussion or ideas by pushing for one particular thing -- this is
>> just a genuine question regarding what is still needed and why.
> Maybe this is controversial, but I think that no single institution should host or control the package (otherwise it would be as if we are working for free for that institution, who would ultimately get the credit). We should just be a collection of individuals, some working in our spare time, some funded to develop software, working towards a common open source project. By using a distributed versioning system (e.g. git or hg) and a free hosting solution (neutral territory, e.g. github or mercurial) we can ensure that the project will live beyond the funding for any given institution, and the distributed aspect means that if the hosting solution goes out of business, moving to another will be easy. Of course it would still be possible for institutions to support development of that package.
> This is akin to the relationship between Enthought and Numpy/Scipy - they help fund the development, but even though the primary Numpy developer is now the Enthought president, the development is not hosted or controlled by Enthought. So I would vote for an institution-independent package on GitHub. But of course this will only work if it is possible e.g. for STScI or Gemini developers to move the packages to a repository not at their institutions, so there are licensing/copyright/funding/political issues to consider (although of course with git, one can have a full local repository). Maybe the STScI and Gemini people on here could weigh in on this? For example, would there be barriers to moving the astrolib packages into a new repository on e.g. GitHub?
> The name astropy has a good ring to it, is in line with numpy and scipy, and would make it clear this does not endorse specifically one of the existing packages. I've reserved the astropy organization on GitHub in case we decide to go down that road.
More information about the AstroPy