[AstroPy] POLL: vision for a common Astronomy package

Erik Bray embray at stsci.edu
Wed Jul 6 14:33:00 EDT 2011

On 07/06/2011 02:06 PM, Perry Greenfield wrote:
> 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

I'll add that in the case of pywcs, although it contains its own copy of 
wcslib, it only compiles the parts of it that it needs and bundles them 
in _pywcs.so.  It does not rely on linking with a separately installed 
copy of wcslib.  So in cases were users already have a wcslib installed 
by the system, this at least will not interfere with it in any way.

I definitely agree that it's ideal to use the platform's packaging 
system to manage all dependencies, but it doesn't hurt to include the 
source code for troublesome dependencies as well.  So long as it's easy 
for system packages to not use the bundled version if desired.  In the 
case of pywcs it's mostly a matter of removing the wcslib portions from 
the _pywcs C extension and instead have it link _pywcs.so with the 
existing wcslib.


More information about the AstroPy mailing list