When Astropy is installed with MacPorts, it fails if pyfits is already installed, because it tries to install the legacy shim:
Error: org.macports.activate for port py27-astropy returned: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pyfits/__init__.py is being used by the active py27-pyfits port. Please deactivate this port first, or use 'port -f activate py27-astropy' to force the activation.
Please see the log file for port py27-astropy for details:
To report a bug, follow the instructions in the guide:
Error: Processing of port py27-astropy failed
This is due to the fact that the package is built in a pristine environment before being moved to the final location, so it doesn't detect if the real packages are already there. We need an option like:
python setup.py build --disable-legacy
To force legacy packages to not be installed.
Fixes #302. Adds a commandline argument `--disable-legacy` to
forcibly disable the installation of legacy shims. This is needed so
one can build and astropy package that does not conflict with pyfits,
I've attached a possible solution to this. It's a little more complicated than I would have liked, but comes out of distutils general inflexibility.
It adds a custom build command class which merely adds the --disable-legacy option. Then, get_distutils_option to get the value of it from within the legacy shim generation code. The problem I ran into is that get_distutils_option did not respect the custom command classes (in cmdclassd). I considered extending get_distutils_option to accept a command class dictionary, but passing it through all the various layers of configuration that don't really care about it was a bit of a mess. I arrived at setting a global variable in setup_helpers.py that get_distutils_option uses. While global variables are generally a bad thing[TM], I think in this case it's probably ok -- I can't conceive of why we might have multiple custom command class dictionaries in use simultaneously, for instance, and multithreading is not an issue in this particular instance. However, I can't help but wonder if there's a better solution...
An alternative (probably equally ugly) is to monkey-patch distutils.command.build.build, rather than inheriting from it and changing to it in cmdclassd.
Hmm... normally I'd be inclined to say inherit as you've done here, but my concern is that this requires some care to keep the cmdclassd for the affiliated package template's setup.py in sync with any future changes.
Perhaps this means we should actually move all of the creation/processing of cmdclassd to setup_helpers.pyinstead ofsetup.py``?
@astrofrog, do you have any thoughts on this?
I don't really have a strong preference on this, so I defer to the two of you.
One idea I was thinking about last week is to actually separate out the installation of the legacy shims, because I'm not sure if most people would want them on by default. So one could have a totally separate setup_legacy.py file in the root directory. But maybe that would make things even harder?