[AstroPy] External packages in astropy
mdroe at stsci.edu
Wed Jun 20 21:01:25 EDT 2012
On 06/20/2012 03:19 PM, Olе Streicher wrote:
> Michael Droettboom <mdroe at stsci.edu> writes:
>>>> 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.
>> 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.
> I had rather good communication with the wcslib author in the past, so I
> would always prefer a bugfixing there (and, obviously, Mark fixed the
> bugs your mentioned). If you find new bugs, I (and probably other
> packagers) would probably also happily include fixes into the packages
> until upstream incorporates them.
>> "extended_ctype.patch" makes wcslib compatible with FITS files that
>> contain SIP information.
> Could you explain this a bit more? It would be interesting for the
> Debian version of wcslib as well.
The SIP convention extends the CTYPE keywords so they have a "SIP"
suffix, for example "RA---TAN-SIP". wcslib by default rejects this as
being an invalid CTYPE. astropy.wcs/pywcs includes SIP support, so we
don't want to raise an exception.
This could be handled outside of wcslib by changing these values before
passing them in, which would give us compatibility with vanilla wcslib
-- that might be a reasonable solution.
>> This patch will not be included upstream for political reasons.
>> Without this patch, astropy.wcs can not support SIP and is thus
>> effectively broken.
> As broken as wcslib itself (I dont't know who of you is right here).
What I meant to apply is that pywcs would be broken because it could not
read SIP any longer, which is one of its important reasons for being.
>> I have been told by the upstream author that MS-Windows compatibility
>> is not something he cares about.
> This is also not python specific. Also, for distribution packaging
> Windows patches are not interesting.
> To summarize: pywcs works well with the original wcslib (especially the
> latest, bugfixed versions),
I would say "only the latest, bugfixed versions". If astropy.wcs links
to the system wcslib prior to 4.13, all of the *fix functions, I
wouldn't say that's "works well".
> and it has the same limitations as the used
> wcslib. If one wants to use SIP, he needs to use a patched wcslib,
> regardless of the programming language (Python or C). Right?
More information about the AstroPy