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

[Olе Streicher]

Hi Erik,

thank you for your fast and extensive answer!

Erik Bray <embray at stsci.edu> writes:
>> * 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 [1] for Fedora Linux (base of
>>    Scientific Linux) and [2] 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
>>    mentioned).
>
> 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?

Good question. I just had a look how pyfits was packaged in Debian and
Fedora and found that they unbundle only zlib, so I concentrated on
that. But since the part from fitsio seems not very small (a ~220k
file), I would prefer to unbundle it as well -- at least if it is used
mainly unchanged.

> 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?)

As far as I know, there is no (documented) decision on that yet.

> 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?

Maybe this may be solved by the link order? Or re-#define these symbols
in the cfitsio resp. zlib header files in io/fits/src?

>> * 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.

OK. There may be a split of the architecture independent files
(python scripts) from the architecture dependent ones (shared libs), but
this is still in discussion yet. It will be also mainly invisible from
the outside.

>> * 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.

The following packages would be created:

* python-astropy (without the directories dist-packages/pyfits/, 
  dist-packages/pywcs/, dist-packages/vo/)
* python-astropy-pyfits 
  - contains the files in dist-packages/pyfits/ from astropy
  - depends on python-astropy
  - conflicts with the original "python-pyfits" package
  - provides a "pyfits" module (like python-pyfits)
* python-astropy-pywcs, python-astropy-votable similarly

Then one can just install python-astropy parallel to python-pyfits, and
"import pyfits" would import the original (separate) package. Or one can
remove the python-pyfits package and install the python-astropy-pyfits
package; then "import pyfits" would use the legacy code from
astropy. Both python-pyfits and python-astropy-pyfits cannot be
installed at the same time; this is prevented by the "conflicts"
attribute. I however need to check whether this fits into the Debian
policy. 

But the machine that creates the packages has nothing to do with the
machine where it is finally installed (Debian provides ready-to-use
binary packages). So, I would like to be able to *create* the pyfits,
pywcs and votable legacy packages even if the original ones are already
installed on my build machine -- I will just put the files in the
according package, and not use it here directly.

The patch for this is quite simple, but a documented switch would be
more robust.

> 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?

I would vote for keeping the default as it is, since for most users the
current way is optimal. It would just be nice to have some special
interface for us packagers :-)

Best regards

Ole