<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 06/20/2012 03:37 AM, Olе Streicher
      wrote:<br>
    </div>
    <blockquote cite="mid:ytzliji5t7w.fsf_-_@news.ole.ath.cx"
      type="cite">
      <pre wrap="">Erik Tollerud <a class="moz-txt-link-rfc2396E" href="mailto:erik.tollerud@gmail.com">&lt;erik.tollerud@gmail.com&gt;</a> writes:
</pre>
      <blockquote type="cite">
        <pre wrap="">On Tue, Jun 19, 2012 at 11:19 AM, Olе Streicher <a class="moz-txt-link-rfc2396E" href="mailto:astropy@liska.ath.cx">&lt;astropy@liska.ath.cx&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">* 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?
</pre>
        </blockquote>
      </blockquote>
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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

<a class="moz-txt-link-freetext" href="http://linuxtesting.org/upstream-tracker/versions/wcslib.html">http://linuxtesting.org/upstream-tracker/versions/wcslib.html</a>

(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. </pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote cite="mid:ytzliji5t7w.fsf_-_@news.ole.ath.cx"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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).

</pre>
    </blockquote>
    You can see our patches to wcslib here:<br>
    <br>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <a
href="https://github.com/astropy/astropy/tree/master/astropy/wcs/patches">https://github.com/astropy/astropy/tree/master/astropy/wcs/patches</a><br>
    <br>
    "compiler_warnings.patch" is not strictly necessary, but nice to
    have.<br>
    <br>
    "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.<br>
    <br>
    I have been told by the upstream author that MS-Windows
    compatibility is not something he cares about.<br>
    <br>
    Mike<br>
  </body>
</html>