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

[Erik Tollerud]

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.



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)

> BTW, astropy-0.1 is now available in Gentoo Linux :)

Thanks - nice and fast!



On Tue, Jun 19, 2012 at 2:04 PM, Joe Harrington <jh at physics.ucf.edu> wrote:
> I'm happy with that, but it should be clearly documented in a central,
> well-known place, so that people know what they can and can't depend on
> to be stable.  If I'm writing software for a spacecraft project or
> instrument calibration pipeline that MUST be long-term stable, I might
> choose to use pyfits (now stable) but not NDData (not stable).  A
> student working on a homework assignment might safely use NDData.


You have a very good point her - can you create an issue in the github
repo about it so we remember to address it?  (I can do it myself, if
you'd rather not, but I prefer for people to "own" good issues that
they raise, if they're willing  -credit where credit is due and all
that.)



-- 
Erik Tollerud