I understand. Maybe it is then better to remove the extension-swapping and
ask the developer to specifically decide which extension is a cython_module
and which is an ext_module (and potentially have duplicate definitions of
the same extension):

    setuptools.setup(
        # ...
        ext_modules=[
            Extension("pure_c", ["pure_c.c"]),
            Extension("mixed", ["mixed.c"]),
        ],
        cython_modules=[
            Extension("mixed", ["mixed.pyx"]),
            Extension("pure_pyx", ["pure_pyx.pyx"]),
        ],
    )

In this case

 - `pure_c` will never automatically be cythonized
 - `mixed` may be cythonized
 - `pure_pyx` may be cythonized

`pure_c` needs the developer to run `cythonize pure_c.pyx` before `python
setup.py build_sdist`. Shipping a package without the resulting .c file
will fail during installation.

`mixed` may come with both .c and .pyx files

 - If cython is not installed setuptools will simply compile the C code.
 - If cython is installed it is up to `cythonize()` to decide if it wants
to re-compile pyx->c first.

`pure_pyx` is similar to `mixed` but it may run into non-obvious problems
if cython is not installed and not defined as a `setup_requirement`: *It
will silently not be built* and be missing from the final installation. I
guess this won't be much of a problem though as it will most probably be
found out quickly and be fixed with a simple additional line in setup.py.



It might be a bit beyond the scope of what I am suggesting here but I have
also been experimenting with adding another keyword argument and another
command to setuptools:

    setuptools.setup(
        # ...
        cython_manual_modules=[
            Extension("pure_c", ["pure_c.pyx"]),
        ],
    )

Combined with

    python setup.py build_pyx

we could then automate the cythonization calls during development. This
removes the overhead of remembering each of your pyx files from the
developer and encourages them to *not write cython-related scripting logic*
in their setup.py.

In your case (you cythonize before sdist and dont want users to cythonize
during install) you would define your package as

    setuptools.setup(
        # ...
        ext_modules=[
            Extension("mixed", ["mixed.c"]),
        ],
        cython_manual_modules=[
            Extension("mixed", ["mixed.pyx"]),
        ],
    )

And would run

    python setup.py build_pyx sdist

to create a distribution file.

Again, all these changes are backwards compatible as none of the current
logic needs to be changed (the additional keyword argument and the command
class have been appended to the GitHub PR).

On Sun, Feb 7, 2016 at 9:38 PM, Greg Ewing <greg.ew...@canterbury.ac.nz>
wrote:

> Nils Werner wrote:
>
>>  - Having `cythonize()` internally automatically compile *.pyx files when
>> *.c files
>>    are provided is disabled by default and must be enabled using the
>> `replace_extension`
>>    keyword argument (`cython_modules` enables that option).
>>
>
> I'd be happier if it were still disabled by default even then.
> If I'm simply installing a package, I do *not* want it to
> try to recompile any .pyx files just because I happen to have
> cython installed.
>
> I know that isn't supposed to happen unless the .pyx is newer
> than the .c, but I wouldn't like to rely on that. There's a
> big difference between using a package and modifying it, and
> I'd rather be explicit about when I'm doing the latter.
>
> --
> Greg
> _______________________________________________
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
_______________________________________________
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Reply via email to