[AstroPy] [astropy-dev] ANN: Astropy v0.1
xarthisius.kk at gmail.com
Wed Jun 20 14:26:44 EDT 2012
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 900 bytes
Desc: OpenPGP digital signature
More information about the AstroPy