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