[AstroPy] POLL: vision for a common Astronomy package

Ole Streicher astropy at liska.ath.cx
Wed Jul 6 11:03:59 EDT 2011

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.

>> For this reason, it would be good if there was a choice of using the
>> original package in case it is already installed instead of the one that
>> was packed with the python package. This would make the life for Linux
>> (Ubuntu, Fedora, OpenSUSE) package creators much easier.

> If there is an ACTIVE choice made by the user, I agree.  The user could 
> choose to use the already-installed package if they need to do that.  

I do not speak so much about "users", but about "package maintainers",
who compile the software and create packages that can then be installed
by the users, taking care of about all the dependencies one would need.

For example, when I packaged pywcs for Ubuntu, I created in two
packages: one with the wcslib (since wcslib was not available for
Ubuntu), and another for the python wrapper itself. The latter package
has the dependency for the lib; if needed one could even specify that a
specific version should be installed. On systems that allow a smart
package management, we should allow (and encourage) to use it as much as
possible. Wouldn't his help for Solaris?

> They can also take responsibility for using a library that our python
> code was never tested with.

I see the problem of incompatible libraries today much less than 10
years ago -- libraries tend to get better documented now, better tested
and have more stable APIs. From this point of view, I dont see a big
difference in updating a required external library, or the system's libm.

BTW, are there ideas for regression tests of astropy? Especially in the
case you mentioned, this would be *very* helpful to check that
everything works in the target system.

> I would object if there is an automatic detector that prefers the system 
> package, primarily because that is a scenario that causes problems for 
> me all the time both as a user and as a support engineer.

My goal is that the use any external package that is used in astropy is
well-documented (which versions are compatible, where to get it etc.)
and if the external package is included in the python package, there
should be a switch to use the external library instead.

Best regards


More information about the AstroPy mailing list