When astropy started, it included the pyfits, pywcs, and vo packages. As discussed in https://github.com/astropy/astropy/pull/1493 , the legacy API (aka, calling `import pyfits`) was removed in astropy 0.3. With the legacy option removed, astropy no longer conflicts with any of the other python package. This bug report is an attempt to fix this. Furthermore, these packages are still having releases seperate from their version in astropy, so it is conceivable that the user may want to use these packages instead of the versions in astropy. Reproducible: Always Steps to Reproduce: 1. emerge astropy 2. Unsuccessfully use a python script that imports pyfits, pywcs, or vo 3. emerge pyfits, pywcs, or vo Actual Results: The emerge fails due to each package blocking astropy (and visa versa) Expected Results: One is able to co-install packages with seperate python modules. I've attached some ebuilds and an eselect module to deal with the one conflict: both pyfits and astropy include fitsdiff and fitscheck. Additionally, dependancies on virtual/pyfits or virtual/pywcs should probably be reconsidered. If packages need to be able to do 'import pyfits' or 'import pywcs', then only astropy-0.2 or pyfits/pywcs can satisify that. Also, pywcs doesn't need pyfits according to their website, and pyfits has a version bump.
Created attachment 369674 [details] Non-blocking ebuild for astropy
Created attachment 369676 [details] eselect ebuild for pyfits/astropy tools
Created attachment 369678 [details] eselect module for fitscheck
Created attachment 369680 [details] eselect module for fitsdiff
Created attachment 369682 [details] Updated pyfits ebuild
Created attachment 369684 [details] Non-blocking ebuild for pywcs
Created attachment 369686 [details] Non-blocking ebuild for vo
Thank you for filing this bug and providing a patch; assigned to the maintainers.
yesterday i committed unblocking to astropy, vo, and pywcs, and changed all virtual while checking reverse dependencies please re-sync your tree. i don't think we need the eselect-pyfits given we'll be removing <astropy-0.3 soon, but i'll see for the fits{check,diff} tools, since there is still a file conflict.
(In reply to Sébastien Fabbro from comment #9) > yesterday i committed unblocking to astropy, vo, and pywcs, and changed all > virtual while checking reverse dependencies please re-sync your tree. > > i don't think we need the eselect-pyfits given we'll be removing > <astropy-0.3 soon, but i'll see for the fits{check,diff} tools, since there > is still a file conflict. Thanks, sorry for missing that. Do you mean that we don't need the virtual/pyfits since <astropy-0.3 will be removed soon? I think there's three ways to deal with the fits{check,diff} tools: 1. Install both, use eselect to switch between them. 2. Make them optional (like with a 'tools' USE flag), and block on the other having that flag set. 3. Rename the tools in one, but not the other. 4. Not install the tools in one Given that the files are basically identical (at least, in pyfits-3.2 and astropy-0.3), I'm not sure what the motivication would be for changing between them, except that you'd probably expect to have fits{check,diff} if either one is installed.
(In reply to Joseph Booker from comment #10) > Do you mean that we don't need the virtual/pyfits since <astropy-0.3 will be > removed soon? yes > 3. Rename the tools in one, but not the other. chosen solution: renamed in pyfits-* + 06 Feb 2014; Sébastien Fabbro <bicatali@gentoo.org> + -files/pyfits-3.0.8-debundle_zlib.patch, -pyfits-3.1.2.ebuild, + pyfits-2.4.0.ebuild, pyfits-3.2.ebuild: + Renamed conflicting binaries to *-pyfits, removed old, thanks Joseph Booker, + bug # 500460 + thanks for your input
how about; + >=dev-python/stsci-distutils-0.3[${PYTHON_USEDEP}] + >=dev-python/d2to1-0.2.5[${PYTHON_USEDEP}]" from setup_requires=['d2to1>=0.2.5', 'stsci.distutils>=0.3'], from portage/dev-python/pyfits-3.2/work/pyfits-3.2/setup.py
+ 10 Feb 2014; Sébastien Fabbro <bicatali@gentoo.org> pyfits-3.2.ebuild: + Fixed minimum version of dependencies +
