Repository navigation
Move io.fits external C dependencies into cextern #318
Description
Once #316 is accepted and merged, the point has been made that some of pyfits'/io.fits C dependencies should be moved to cextern for ease of system packagers replacing them with system libraries. In the case of io.fits this applies to zlib and the borrowed pieces from CFITSIO.
The zlib bits are actually there in part because they're also included in CFITSIO. So one unresolved question is: Do packages for CFITSIO (such as on Debian or Gentoo) pull out CFITSIO's included zlib as well? Should zlib be included in cextern as a separate third-party library, or as part of CFITSIO?
Activity
eteq commentedon Jul 12, 2012
Do you ever use zlib directly, or is it only used by way of CFITSIO?
Also, I think this is what you meant, but you probably also want to modify
io.fitsto support the #316 way of allowing system libraries - e.g., allow a--use-system-cfitsiooption.embray commentedon Jul 12, 2012
Only by way of CFITSIO as far as I can tell.
And yes, support for --use-system-foo was implied :)
eteq commentedon Jul 12, 2012
In that case, I'm tempted to say keep it inside cfitsio. Otherwise you have to figure out how to deal with the separate cases of
--use-system-cfitsio,--use-system-zlib, both, and neither. And we really don't want to have to build our own dependency/package tool for these external libraries.embray commentedon Jul 13, 2012
I think that's where I'm leaning as well. If we use system cfitsio then it's up to the system packager to care whether or not zlib is packaged with cfitsio or is made a dependency. It doesn't really matter to us at that point.
timj commentedon Jul 16, 2012
In answer to the first question, the debian cfitsio3 package does list zlib as a dependency: http://packages.debian.org/sid/libcfitsio3
embray commentedon Oct 10, 2012
This might be difficult to get done for 0.2, but I'll try. The problem is that pyfits/astropy.io.fits does not use CFITSIO in any recognizable sense--it uses heavily modified pieces of CFITSIO that cannot be replaced by a system CFITSIO.
I did make enormous progress during the SciPy sprint on getting the fits compression working with normal CFITSIO, but there are still a few cases that aren't working yet, and that will require me to refactor how pyfits handles the data heaps used by variable-length array data columns. I have ideas for this but haven't been able to try them out yet. If the ideas I have do work without much hassle then this can probably get done :/
embray commentedon Nov 19, 2012
This work is finally mostly finished in PyFITS as documented at https://trac.assembla.com/pyfits/ticket/169
Once I merge that work in to Astropy I can tie up the loose ends by adding a
--use-system-cfitsio. I agree with that zlib should remain bundled with cfitsio. If a system packager wants to remove Astropy's cfitsio in preference for their own, it's 100% certain that that their cfitsio will include the appropriate solution for zlib if their cfitsio package works at all.embray commentedon Nov 26, 2012
This was auto-closed by a commit in a branch that I didn't mean to push to the main repository.
embray commentedon Dec 5, 2012
This is fixed by #495.This is fixed by #495.
Merge branch 'fits/astropy' into astropy
Merge pull request astropy#318 from bsipocz/typing_import
Merge pull request astropy#318 from pllim/special-js