[AstroPy] External packages in astropy

Michael Droettboom mdroe at stsci.edu
Wed Jun 20 14:22:01 EDT 2012

On 06/20/2012 03:37 AM, Olе Streicher wrote:
> Erik Tollerud <erik.tollerud at gmail.com> writes:
>> On Tue, Jun 19, 2012 at 11:19 AM, Olе Streicher <astropy at liska.ath.cx> wrote:
>>> * I very much like the idea of having the external C code in a specific
>>>   diretory tree "cextern" since this makes it easier to split this part
>>>   and use the versions provided with the OS. I would guess that also
>>>   the "wcslib" part will move from pywcs to cextern?
>> Mike D (the maintainer of astropy.wcs and pywcs) will know for sure,
>> but I think his plan is to keep wcslib where it is, because the
>> python-level wrapper is rather closely tied to the particular version
>> of wcslib.
> I don't see this tight bound to a specific version. pywcs/astropy.wcs
> uses the official API of wcslib, so it should work with every
> version. And the shared library contains a SONAME that is going to be
> changed if binary compability breaks.
> Source and binary compability can be checked with the upstream tracker
> http://linuxtesting.org/upstream-tracker/versions/wcslib.html
> (which is down in the moment I write this), and this shows that the last
> versions (from 4.8, if I remember correctly) are all compatible.

I don't see how this proves that case.  API stability has no reflection 
on correctness.  There are bugfixes to the error handling in 4.13 that 
allow the astropy.wcs unit tests to pass, that do not pass with previous 

>> The idea is that cextern is for C code that is essentially included
>> "wholly" (like extern), and things that are tightly coupled to the
>> python code (including Cython .pyx files) will live in the python
>> source tree.  There's more about this is in the README file in the
>> cextern directory.
> When astropy is packaged for a distribution (probably others than Debian
> and Ubuntu as well), there is a need to replace convienience copies of
> third-party code by references to the according packages. Making this
> easier is IMO one of the uses of cextern. I would even suggest to rename
> it to "thirdparty" of similar, since this is probably not limited to C
> code.
> At least, it would be nice to have build-time configuration options to
> use external packages instead of the distributed ones (adjustable since
> the external packages may vary between the Linux distributions).
> I would also suggest a rule that external packages should be used
> unchanged in the astropy tree (if changes are needed, they should be
> discussed/included with the original authors).
You can see our patches to wcslib here:


"compiler_warnings.patch" is not strictly necessary, but nice to have.

"extended_ctype.patch" makes wcslib compatible with FITS files that 
contain SIP information.  This patch will not be included upstream for 
political reasons.  Without this patch, astropy.wcs can not support SIP 
and is thus effectively broken.

I have been told by the upstream author that MS-Windows compatibility is 
not something he cares about.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120620/a25c1bb7/attachment.html>

More information about the AstroPy mailing list