<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">In a private communication with Mark
      Calabretta and Ole Streicher, I have learned that these patches
      will be included upstream.&nbsp; 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).<br>
      <br>
      Mike<br>
      <br>
      On 06/20/2012 02:22 PM, Michael Droettboom wrote:<br>
    </div>
    <blockquote cite="mid:4FE214C9.3030201@stsci.edu" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div class="moz-cite-prefix">On 06/20/2012 03:37 AM, Ol&#1077; Streicher
        wrote:<br>
      </div>
      <blockquote cite="mid:ytzliji5t7w.fsf_-_@news.ole.ath.cx"
        type="cite">
        <pre wrap="">Erik Tollerud <a moz-do-not-send="true" 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&#1077; Streicher <a moz-do-not-send="true" 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
&nbsp;diretory tree "cextern" since this makes it easier to split this part
&nbsp;and use the versions provided with the OS. I would guess that also
&nbsp;the "wcslib" part will move from pywcs to cextern?
</pre>
          </blockquote>
        </blockquote>
        <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 moz-do-not-send="true" 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.&nbsp; API stability has no
      reflection on correctness.&nbsp; 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>
      <a moz-do-not-send="true"
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.&nbsp; This patch will not be included
      upstream for political reasons.&nbsp; 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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
AstroPy mailing list
<a class="moz-txt-link-abbreviated" href="mailto:AstroPy@scipy.org">AstroPy@scipy.org</a>
<a class="moz-txt-link-freetext" href="http://mail.scipy.org/mailman/listinfo/astropy">http://mail.scipy.org/mailman/listinfo/astropy</a>
</pre>
    </blockquote>
    <br>
    <br>
  </body>
</html>