[AstroPy] POLL: vision for a common Astronomy package

Perry Greenfield perry at stsci.edu
Wed Jul 6 14:06:41 EDT 2011


On Jul 6, 2011, at 11:03 AM, Ole Streicher wrote:

> Am 06.07.2011 16:21, schrieb Mark Sienkiewicz:
>> I often have the opposite problem -- the package that the system
>> provides is the one that is older and broken.  For example, every  
>> one of
>> my Solaris machines already has BLAS installed, and every one of  
>> them is
>> missing a function that scipy needs.  At times, I've had to make
>> difficult hacks to autoconfigs to make it use the copy of some  
>> library
>> that I provide.
>
> Sorry, but I would call "Solaris" a really special case -- there is
> probably only a very small percentage of users in that use this  
> system.
> IMO, the easy installations should run on common systems, which are  
> the
> major Linux flavors and MacOSX.
>
Sure, Solaris is the extreme example, but not the only case. We do see  
similar issues on other platforms at non-negligible rates. MacOSX has  
this issue due partly to the number of different ways people may  
install unix-derived software.

I'll also note that existing package dependency systems do not solve  
all dependency conflicts either. There is simply no substitute for  
testing known combinations of versions of libraries as opposed to  
hoping that the one you pick up on a particular system actually works  
with what you have. Things may be better now than in the past, but  
they sure are far from foolproof yet. Thus, bundling as much together  
(particularly the troublesome libraries) is about the only sure way of  
ensuring consistency. This is the approach that Guido has long  
advocated for ensuring reliable distributions (well he used to, I  
don't know he's since changed his mind). And if it doesn't collide  
with the other versions of the library on the system (e.g., you don't  
use ld_library_path or its equivalent), is the wasted disk space  
really an issue these days given terabyte drives are a dime a dozen  
(or will be soon :-)

Perry




More information about the AstroPy mailing list