[AstroPy] [astropy-dev] ANN: Astropy v0.1

[Kacper Kowalik]

On 20.06.2012 20:12, Michael Droettboom wrote:
> On 06/20/2012 01:44 AM, Erik Tollerud wrote:
>> 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.  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.
> 
> Yes.  I also like the modularity of it -- if you want to produce an 
> astropy without astropy.wcs, just delete the astropy/wcs directory. (Not 
> that one would do that -- it just helps with maintenance down the road).
> 
>>
>>
>>
>> On Tue, Jun 19, 2012 at 12:02 PM, Kacper Kowalik
>> <xarthisius.kk at gmail.com> wrote:
>>> speaking of which, are you willing to accept patches to make usage of
>>> cextern/* as well as astropy/extern/*, optional?
>> That's definitely in the pipeline as part of a larger system for
>> dealing with optional dependencies, including things like scipy and
>> matplotlib that we do *not* plan to bundle - see
>> https://github.com/astropy/astropy/issues/63. If you want to take a
>> stab at it, feel free! (Although you might want to email me separately
>> if you want to dive into this, as it probably requires some thought
>> about how to hook it into other parts of astropy)
> 
> For what it's worth, the only library in cextern at present is expat.  
> If it fails to build, astropy.util.xml has fallback Python code to work 
> around it (it will be much slower, of course).  Using the system expat 
> is tricky, because the expat has to be configured the way we expect it 
> to be (basically that its expat_config.h is the same as ours), and I 
> don't think that's a given everywhere.

I wish it was only that :/ I've just got security notice from our QA
team about bundled zlib. It's not astropy issue per se, rather pyfits'
one. Is that zlib copy modified somehow, if not is there a reason not to
use system library?
Cheers,
Kacper

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/astropy/attachments/20120620/8d136573/attachment.sig>