[AstroPy] Deployment and packaging

[Vicki Laidler]

I too think that the goal of this effort should neither start with yet another python distribution, nor produce a mixed general-purpose astronomy library containing IRAF, SExtractor, or whathaveyou. Both those items produce significant barriers at both ends (the developer/deployment end, and the user/installation end). 

Let's at least start out by shooting for a scikit-like python library (C extensions allowed(?)) so that people who really just want a coherent python astronomy library (a la the Astron library in IDL) can have one, and people who want to make a more general astronomy library (like the unified release) can include the resulting product as part of it.

Meanwhile, we can work on collecting some survey data from our potential users, segmented by the various user communities of interest -- I thought Andrew's point that it's the more expert users we want to attract to the project was a very good one; and if need be, revisit the question when we have actual measured data rather than anecdata on which to base the decision.

Vicki

________________________________________
From: astropy-bounces at scipy.org [astropy-bounces at scipy.org] on behalf of Andrew Williams [andrew at physics.uwa.edu.au]
Sent: Wednesday, June 15, 2011 12:01 AM
To: astropy at scipy.org
Subject: Re: [AstroPy] Deployment and packaging

On 15/06/2011 10:43 AM, Tommy Grav wrote:
>
> On Jun 14, 2011, at 10:11 PM, Perry Greenfield wrote:
>> IRAF is only one example. SExtractor is another. And there are
>> others. There isn't yet enough to replace these, and won't be for
>> some years (if ever, it is probably silly to think everything we
>> need will be in Python, or that there won't be some very useful
>> things out there not written in Python).
>
> My opinion is that those tools belong in as separate packages. To me
> they just don't

I strongly agree - people who work with tools like these already will be
_less_ likely to adopt an 'astropy' package if it also includes an extra
copy of SExtractor, IRAF, and every other tool they might possibly want,
generating conflicts with anything that's already installed.

'All in one' setups like this make life easier for people setting up new
computers for training workshops or for new postgrads, but they make
life a lot harder for people who already have the tools they need set
up, and don't want to break them by installing some monolithic
collection of loosely coupled packages. It's that latter set of expert
users who are the ones you most want to get involved using and
contributing to the collection...

For the same reason, I'm also very much against the idea of turning this
into another complete python distribution. Apart from Windows users,
most people already have Python installed with the operating system.
Installing a second copy (and getting all the other libraries you want
to use installed under _both_ Python versions) is a real pain.

There's nothing to stop people re-packaging 'astropy', or whatever the
Python-only collection gets called, along with SExtractor, IRAF, numpy,
and everything else, if there is demand for an 'all in one' collection.

I'm more used to catering for the other end of the user base - the
people who, at worst, _only_ have access to software that's part of the
default OS install, or at best, packages maintained in the ubuntu/fedora
software systems. For example, I wrote a pyfits-like FITS file library
in pure Python for people who couldn't get pyfits installed on the
machine they had to use...

Another point - if this 'astropy' collection is maintained as a
ubuntu/fedora package (plus the OSX equivalent, I forget the name), it
will expand the available user base hugely - an awful lot of people use
computers they don't have root access for. It's really, really hard to
convince most sysadmins to download some random piece of software off
the internet and install it on a machine unless it's maintained in the
software packaging system for that OS.

The more things you add, like SExtractor and numpy (which are both
already distinct ubuntu packages), the harder it will be to package it
properly that way.

Andrew

_______________________________________________
AstroPy mailing list
AstroPy at scipy.org
http://mail.scipy.org/mailman/listinfo/astropy