[AstroPy] AstroPy Digest, Vol 58, Issue 16

[Matthew Turk]

Hi Tom,

On Tue, Jun 14, 2011 at 11:20 AM, Thomas Robitaille
<thomas.robitaille at gmail.com> 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.

With the Enzo (astrophysical simulation) community we found this 100%
to be the case.  We moved from SVN to mercurial hosted on Google Code
(which does allow for forking!) mirrored on BitBucket, in a specific
attempt to move it off the site of a given institution.  Moving to a
neutral location and toward a community-driven development model has
resulted in a huge number of improvements and a great expansion of the
developer and user bases.

For what it's worth, in our community we have a large buy-in for
mercurial (with a number of extensions and value-adds that directly
call the API).  I recognize that the observer and simulation
communities do not necessarily need as much direct cross-talk as
intra-community collaborations, but I felt I should put this out
there.

-Matt

>
> 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?

Whether or not Enthought controls the development, they do drive a
substantial amount of it -- such as the datetime dtype, the Cython
refactoring, and the .NET wrapping.  One should expect such de facto
relationships to grow during the development of an astrophysical
python library, and it's not such a bad thing.

-Matt

>
> 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.
>
> Cheers,
> Tom
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>