[AstroPy] External packages in astropy
mdroe at stsci.edu
Tue Jun 26 10:12:05 EDT 2012
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).
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
>> (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
>> 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.
> AstroPy mailing list
> AstroPy at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the AstroPy