[AstroPy] [astropy-dev] ANN: Astropy v0.1
Tue Jul 10 09:43:38 CDT 2012
Hi, thanks for your work on the Debian packaging. A few replies to your
questions inline below:
On 07/10/2012 03:38 AM, Olе Streicher wrote:
> Dear Astropy developers,
> email@example.com (Olе Streicher) writes:
>> * I would volunteer to do the packaging for Debian (and Ubuntu).
> I now had some time to look a bit deeper into the packaging of astropy;
> is the git repository. The package is not yet ready to use, however.
> I have now some questions and comment on the package:
> * Will astropy.io.fits be an integral part of astropy, and pyfits remain
> just as a legacy (just like astropy.wcs resp. pywcs)? Or does astropy
> just include the latest version of pyfits?
You can consider astropy.io.fits an eventual replacement for pyfits,
though pyfits by itself will still be in development for a while. I am
trying to time things so that astropy.io.fits is as close as possible to
an actual release of pyfits. For that matter, it would be a good idea
to include something in the documentation to this effect.
To be specific: Astropy 0.1 can be considered a replacement for pyfits
3.1 (which is not yet released, but won't be much different).
> * astropy.io.fits also contains some third-party-library code (libz)
> that could be replaced by linking to the library. Many Linux
> distributions unbundle this -- see  for Fedora Linux (base of
> Scientific Linux) and  for Debian (and Ubuntu). I think that the
> astropy package is a good opportunity to make the code cleaner here
> and move this external code to cextern/ and having some options to use
> external libraries instead (like the wcslib/pywcs issue I already
Agreed. In addition to libz, io.fits bundles a few *pieces* of cfitsio,
but not the entirety of it. Would you want to unbundle that too? In
any case, moving it to cextern as you suggest. (I don't remember the
conclusion of the wcslib dicussion--was it going to be moved into
cextern as well?)
The only problem I see is that in some of the zlib and cfitsio files,
function names were renamed with a _pyfits_ prefix to prevent binding
those symbols to the system versions of those libraries at runtime. I
would need some way to resolve this--perhaps a define in a header file
somewhere. Any ideas?
> * In the moment, I would just build astropy as one large package. I
> think that it does not make sense to split it up into smaller
> packages. The documentation would be separated, however (it is not
> built yet).
Agreed--breaking astropy into multiple packages I think would eliminate
the point. Especially considering future goals to make all the
sub-packages more cohesive with each other.
> * Since also legacy packages for pyfits, pywcs and vo are build (what
> about asciitable?), I would create for each of them a small legacy
> package that depends on the main package and provides the legacy
> namespace. However, the legacy namespace is only installed if the
> original is not found, which makes a package creation a bit
> instable. It would be nice if the legacy package creation could be
> forced even if the original package is installed. I could do this
> however by patching setup_helpers.py.
I'm not sure I understand entirely--if I install the python-pyfits
Debian package (or whatever it's called), and then install
python-astropy, if it forces installation of the legacy shim for
'pyfits' that would break python-pyfits.
Or are you suggesting that python-astropy would specify that it
*replaces* python-pyfits and then have it force installation of the
legacy shim? I would caution against that, since it might be replacing
python-pyfits with a different, slightly incompatible version of pyfits.
Are there any packages that depend on python-pyfits that this could break?
More information about the AstroPy