[AstroPy] External packages in astropy

[Michael Droettboom]

In a private communication with Mark Calabretta and Ole Streicher, I 
have learned that these patches will be included upstream.  I 
misunderstood the source of the earlier objections -- the SIP 
compatibility patch is considered reasonable for upstream and will allow 
wcslib to accept SIP without actually supporting itself (which is a 
reasonable thing to do).

Mike

On 06/20/2012 02:22 PM, Michael Droettboom wrote:
> 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 versions.
>
>>> 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:
>
> https://github.com/astropy/astropy/tree/master/astropy/wcs/patches
>
> "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.
>
> Mike
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


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