I was using pyfits via --enable-legacy. After running into issue #1488 I updated the import pyfits to from astropy.io import fits in all my code, which took only a few minutes. It should be easy for everyone else to update their package and scripts, too. +1 to removing --enable-legacy now.

Note that --enable-legacy often refuses to install astropy like this:

$ python setup.py install --enable-legacy --user
------------------------------------------------------------
The compatibility packages cannot be installed because the
following legacy packages are already installed:
    * pyfits
    * vo
    * pywcs

The compatibility packages can only be installed if none of
the corresponding legacy packages are present.
------------------------------------------------------------

I did get this on a machine where a very old pyfits version was installed in the system Python site-packages and I wanted to install a recent version of pyfits and astropy in the user site-packages ... refusing to install the pyfits legacy shim was not the behaviour I wanted in this case.

I'm going to attach a pull request to this issue - it doesn't mean we should merge it, but it's there in case we want to.

Hey look @taldcroft, it's your favorite kind of pull request ;)

👍

👍, even though we're flushing many hours of figuring out dark recesses of Python package installation down the drain 😉

@mdboom - yeah, I do feel a little sad when we get rid of things that were so painful to put in place! I'm just hoping it will save us more hours of maintaining it ;)

Anyway, this is just a suggestion and if people feel we should keep it, then I'm open!

[copying from my posting to astropy-devel]
I have a slightly opposite view. There is very much older software flying around that still uses pyfits and pywcs. And they will continue at least until astropy-1.0 is out (but probably years longer).

Astropy-legacy would allow to drop the standalone pyfits/pywcs packages very soon and still keep this older software. And, at the end, the transition would be easier, since they already use the identical code (just with a different name). This lowers the psychological barrier for the transition.

What I would propose:

• keep astropy-legacy
• remove pyfits, pywcs, and vo.table in favour of astropy-legacy once astropy-1.0 is out
• on some later time, mark the legacy packages as deprecated.

I must, however, also state that the use of the legacy packages so far in Debian is negliglible, as far as the limited statistics can tell: 18 installations of astropy, but only one for -legacy. pywcs has 39, pyfits 177 installations. So, I feel still free to remove the legacy packages.

@embray @perrygreenfield - do you have any opinions on this?

I don't have any strong feelings I don't think. It was a neat hack and I wish it could have had more uptake, but it seems like in practice it's been easier for people to just make the switch. I'm all for removing code until there's nothing left to remove :)

Just so we're clear, merging this would mean removing the astropy-legacy from debian, but leaving in pyfits, pywcs and vo.table for the forseeable future, right @olebole (possible eventually deprecating them, though?)

I'm fine with that plan. I agree with @embray that it seems more like anyone who actually is willing to bother installing astropy is willing to switch to astropy.io.*...

OK, so let's remove the legacy code here. Switching is really easy, and the legacy option will have problems with the version numbers anyway...

I will merge this pull request in a few hours if there are no other comments! If we ever want to re-enable this kind of functionality, at least we have the current code in the git history to start from.

Please note that the above broke compatibility with scikit.image and veusz and it's no longer possible to use astropy as a replacement for pyfits.
It would minimize the noise if the needed changes are pushed to the above projects.