.py in the sky

Musings on Python, Astronomy, and Open Science

Are we acknowledging tools and services enough in Astronomy papers?

A couple of weeks ago, I attended the 5th .Astronomy meeting, which took place in Boston. For anyone not familiar with this series of conferences, the aim is to bring together researchers, developers, and educators/outreach specialists who use or are interested in using the web as a tool for their work (I like to think of it as an astro-hipster conference!).

One of the topics that comes up regularly at .Astronomy meetings is the question of credit: how do we, as scientists, get credit for work that is not considered 'traditional', such as (but not limited to) creating or contributing to open source software, outreach activities, or refereeing? Sarah Kendrew already summarized the discussions on this topic in her blog, so I won't repeat them here. However, given that I contribute to a number of open source projects (such as Astropy, APLpy, and many others) this got me wondering how often authors actually acknowledge the tools that they use in papers?

I previously played around with the NASA/ADS full-text search, but what I wanted was a way to be able to do this automatically for any keyword/phrase, and be able to see the evolution of acknowledgments over time. With the release of the ADS developer API (which Alberto Accomazzi presented on the Monday at .Astronomy), I finally had the tool I needed to do this! This was a fun post-dotastro hack, for which I now present the results below.

Astropy: Google Summer of Code!

astropy

As one of the co-ordinators of the Astropy project, I am very happy to announce that two talented students will be joining the Astropy project as part of this year's Google Summer of Code (GSoC)!

For anyone not familiar with GSoC, it is a great program that allows students around the world to spend the summer contributing to an open source project (the students receive a stipend from Google for their work). Astropy is participating in GSoC as a sub-organization in the Python Software Foundation organization.

How to conduct a full code review on GitHub

Why we might want to do it

I think it's fair to say I'm addicted to using GitHub. I've used it so much in the last couple of years that I don't understand/remember how we got any serious collaborative coding done before. In particular, the ability to comment on code line-by-line, having conversations, updating the pull requests, and merging them with a single click is in my mind so much more rewarding and productive than having to comment on a patch in an email discussion.

However, I occasionally want to do a full review of a package that someone else has written, and comment on various parts of the code. While it is possible to leave line-by-line comments on a commit-by-commit basis, GitHub does not provide an official way to review the latest full version of a file or package.

What Python installations are scientists using?

Back in November 2012, I asked Python users in Science to fill out a survey to find out what Python, Numpy, and Scipy versions they were using, and how they maintain their installation. My motivation for this was to collect quantitative information to inform discussions amongst developers regarding which versions to support, because those discussions are usually based only on guessing and personal experience. In particular, there has been some discussion in the Astropy project regarding whether we should drop support for Numpy 1.4, but we had no quantitative information about whether this would affect many users (which motivated this study).

In this post, I'll give an overview of the results, as well as access to the (anonymized) raw data. First, I should mention that given my area of research and networks, the only community I obtained significant data are Astronomers, so the results I present here only include these (though I also provide the raw data for the remaining users for anyone interested).