[AstroPy] Co-ordinating Python astronomy libraries?

Perry Greenfield perry@stsci....
Thu Jul 8 13:03:36 CDT 2010

replying to the answer to the question I posed...

On Jul 7, 2010, at 2:30 AM, Erik Tollerud wrote:
>> For those reluctant, we are curious about what the main obstacles  
>> are.
> I'm not exactly clear on what the repository you're speaking of
> encompasses (and hence what the obstacles are).  Is this just a
> repository storing a whole bunch of seperate packages, or actually a
> common package that is distributed with a single "python setup.py
> install"?
Well, more the former, but also to enable something along the latter  
(though not necessarily part of a single install). When things are  
here and there, it is more difficult to package those together in an  
automatic way. Not impossible, just more work and more ways for things  
to go wrong.

> If it's the former, the main thing in my mind is that it seems highly
> redundant - there around exist repositories that are excellent (google
> code, launchpad, bitbucket, github, etc.), and It's not clear to me
> what is gained by making an "astronomy repository" when these other
> options are most likely to have anything we would need and probably
> will be more consistently maintained/upgraded given that they
> typically are focused on just being a hosting service.  I also am

We are talking about using a managed hosting service (commercial in  
this instance).

> definitely not a fan of Trac or SVN.  The issue with Trac may be
> mostly just personal preference - it always just seems kind of clunky,
> behind-the-times, and difficult to use, although maybe I just didn't
> try hard enough.   SVN, though, would be a non-starter -- distributed
> VCS like Mercurial, git, or Bazaar are much better suited to the
> rather common astronomy situation of a bunch of individuals hacking
> away at something when time permits, while still supporting the
> standard SVN/CVS-like centralized workflow.
But trac is fairly portable since it is widely used. Migrating the  
info from some of the others can be a  more difficult problem (lock-in  
issues). As for svn, git, hg, bazaar issues, nothing is going to  
satisfy everyone, I agree.

> If it's the latter, the biggest problem to me is that all of a sudden
> it becomes *much* harder to manage distribution and have control over
> the "vision."  I also can't help but think installation and
> dependencies would quickly become a huge hassle given the huge
> diversity of hardware and software needs that various parts of the
> astronomy community generally has.  This is the main thing that would
> make me leery of a centralized build/testing scheme of the depth
> described above - lots of astronomers want to hack something quickly
> together that "just works" and will not bother if they have to jump
> through many hoops to contribute.
If it is something hacked together quickly with little interest in  
making it generally useful or consistent, then I agree, it probably  
shouldn't be part of the repository (nor any standard distribution I  
argue). We're talking about things that seem to be beyond  that.
> In my mind, the most useful thing in the short-term would be a
> centralized (and actually close-to-complete!) listing of astronomy
> packages well-organized by topic, with the *option* of having that
> site also be the repository/host/bug tracker/wiki.  There would be an
> expectation that listed packages clearly specify their requirements
> and post them to pypi.python.org in the standard setup.py way .  All
> the mechanisms already exist within distutils and distribute - it
> there's an organized listing, it's trivial to write scripts that will
> use the already-existing pypi mechanisms to either generate
> metapackages as described above, or install various groupings of
> astronomy packages even if the extras option disappears.  It's not
> quite as straitforward, but still probably only moderately difficult
> to combine these into system-specific packages.  The could also be
> lots of neat ways to encourage people to combine closely related
> packages using this sort of scheme.   It seems to me this can greatly
> simplify the distribution problems while still leaving a lot of
> flexibility for a community that's famously (notoriously?)
> independently-minded.
That works to a certain level. But before long, there are n flavors of  
representing this and that, and combining 10 packages like this to use  
in your own  code can get to be a real chore. You'll spend a lot of  
time moving from one convention to another (and not catching some  
bugs). I don't think making everyone conform is a good solution, but  
eventually standardizing on core libraries is a very good thing in the  
long run. I think there is a reasonable middle ground on this kind of  
>> AAS splinter meeting, anyone?
> +1

So most of the contributors are more likely to be at AAS than ADASS?  
That says something interesting about ADASS methinks.


More information about the AstroPy mailing list