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

[Erik Bray]

On 07/10/2012 11:33 AM, Olе Streicher wrote:
> Hi Erik,
>
> thank you for your fast and extensive answer!

No problem :)

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

I'm probably going to make some updates in the future to exactly how 
pyfits goes about including the bits of CFITSIO that it does, but in 
general I don't think there should be any problem with unbundling it.

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

That all makes sense.  I could see adding an install option for forcing 
installation of legacy packages.  Feel free to add an issue report on 
GitHub for that; or I can add one.

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

Agreed--this seems reasonable.

Erik B.