Repository navigation
Conversation
The code adds a new sub-package astropy.skypy. This has two
modules skyc and astrom, both of which are Cython extension
modules. The skyc extension calls functions in an external
library skycalc. The astrom extension is a standalone extension.
The skycalc library source code is included in cextern/skycalc.
The user, one who is installing astropy, can set a few
configuration options for skypy, which will determine whether
astropy will build skypy.skyc using the cextern source code or
using precompiled library in the user's machine. Currently the
setting is in skypy/setup_package.py. In production this will be
in ~/.astropy/skypy.cfg or equivalent.
The developer sets up one or both of get_cython_pyx_extensions()
and get_cython_extensions() functions in skypy/setup_package.py.
The astropy setup.py file will call the former if the condition
``HAVE_CYTHON and not release`` is True, and the latter if the
condition is False. In addition, astropy setup.py will add
Cython.Distutils ``build_ext`` command to ``cmdclass`` dictionary
if the above condition is satisfied.
In the get_cython_pyx_extensions() function, the developer will
return setuptools ``Extension``s that directly use Cython pyx
files. In the get_cython_extensions() function, the developer
will return setuptools ``Extension``s that use Cython generated
C files only. These Extensions will be constructed with
parameters consistent with user's library option.
With the current set of files we can perform the following:
$ python setup.py develop # Bundle of warnings from skycalc.c.
$ ipython
>>> import astropy
>>> astropy.test("skypy")
================================== test session starts ========
platform linux2 -- Python 2.6.6 -- pytest-2.1.3
collected 1 items
astropy/skypy/tests/test_simple.py .
=============================== 1 passed in 0.02 seconds ======
0
>>> from astropy import skypy
>>> skypy.astrom.hello("d")
Hello d!
>>> skypy.skyc.dow(2451545.0)
5.0
|
This is definitely along the lines of something we need to be doing. You're absolutely right that the Cython compilation steps need to be fixed. I strongly disagree that Cython should have to be explicitly compiled. The reason for C code requiring explicitness is that it has a lot more conflicting choices because it's generally intended for wrapping C-libraries. Cython, by contrast, can be easily used simply as a compiled plug-in to speed up something. So we want to make that as easy as possible by having the setup automatically do the typical use cases (e.g. numerical operations, sometimes with numpy arrays). But you're absolutely right that the option to do it explicitly needs to be present, and your solution here makes sense, I think. Also, I'm closing this pull request because you said this is not intended to actually be merged. FYI, pull requests should be used when you actually want something pulled into master, rather than to illustrate an example. This sort of thing is ideal to post on astropy-dev, with a link like phn/astropy@astropy:master...cython-example to get something like the pull request look |
|
Hello,
Thanks,
|
I foresee plenty of people who want to write C-speed code but don't want to have to deal with the
That's what I figured, so it's totally fine - just wanted to mention so you'd know about the alternative in the future. |
|
Oh, and by the way, your example here is a perfect test as an affiliated package once we have that all up and running, given that it has a not-so-straightforward approach for setup. If we can get the automated scripts to install this correctly, they should be able to handle just about anything Cython can throw their way! |
Refactor AstropyTest to make it easier to subclass.
add imexam as affiliated package
2 participants
Cython extension discovery should be treated the same way as the regular C extension discovery currently implemented; explicitly asking the developer and not automatic discovery. These commits implement a Cython extension discovery scheme that gives developers control over the extension building process. The scenario implemented here is probably as involved as it can be. This is an example, and not intended for direct merging.
The code adds a new sub-package
astropy.skypy. This has two modulesskycandastrom, both of which are Cython extension modules. Theskycextension calls functions in an external library Skycalc. Theastromextension is a standalone extension.The Skycalc library source code is included in
cextern/skycalc. The user, one who is installing astropy, can set a few configuration options forskypy, which will determine whether astropy will buildskypy.skycusing the source code incextern, or using pre compiled library in the user's machine. Currently the setting is inskypy/setup_package.py. In production this will be in~/.astropy/skypy.cfgor equivalent.The developer defines one or both of
get_cython_pyx_extensions()andget_cython_extensions()functions inskypy/setup_package.py. The astropysetup.pyfile will call the former if the conditionHAVE_CYTHON and not releaseis True, and the latter if the condition is False. In addition, astropysetup.pywill add Cython.Distutilsbuild_extcommand tocmdclassdictionary if the above condition is satisfied.In the
get_cython_pyx_extensions()function, the developer will return setuptoolsExtensioninstances that directly use Cythonpyxfiles. In theget_cython_extensions()function, the developer will return setuptoolsExtensioninstances that use Cython generated C files only. TheseExtensioninstances will be constructed with parameters consistent with user's library option.With the current set of files we can perform the following:
We can now clean up, set the
USE_SIN_FUNC_LIBoption inskypy/setup_package.pyand re-run the command. This time the library in~/libwill be used. The header fileskysub.hmust also be in~/lib.The library can be created using
Note:
USE_SIN_FUNC_LIBis left over from test code; forgot to rename toUSE_SKYCALC_LIBor something else.