On Thu, 2012-09-13 at 10:44 +0200, Tarek Ziadé wrote: > On 9/13/12 10:15 AM, Chris McDonough wrote: > > Some packages we maintain currently provide largely identical > > side-by-side implementations of features: one implementation is written > > in C, the other implementation is written in Python. The C module is > > just an optimized version of the Python code. > > > > There is logic at module scope within modules in the same package which > > attempts to import the C version. If the C version cannot be imported > > (an ImportError is raised), the logic falls back to importing the Python > > version: > > > > try: > > from . import cmodule as module > > except ImportError > > from . import pymodule as module > > > > This means that the package can be used if the C implementation is > > compiled or not. It will run more slowly, but that's OK in lots of > > cases. > > > > In our setup.py for these kinds of distributions, we have code which > > under Py2 uses a setuptools "feature" and under Py3 registers a > > different kind of build_ext which, at install time, will: > > > > - Attempt to compile the C if suitable build tools seem to exist on the > > target system. > > > > - If suitable build tools don't seem to exist on the target system, will > > print a message and continue. > > > > How can we support such a feature in the brave new declarative packaging > > world? > > > > - C > > > FWIW there's an 'optional' option for the Extension class in Python 2.7 > in distutils. > > see > http://hg.python.org/cpython/file/9b40d018e4cf/Lib/distutils/command/build_ext.py#l458 > > If the compilation fails it just warns and continues. > > That option is also present in distutils2, so you can use it in the > setup.cfg file. > > Does that work ?
Yep. - C _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
