Failed getting this to work

[itamarst]

I was very glad to see this existed but I cannot figure how to use it.

I want to have a .py file that is both importable from Python and compiled via Cython (so we can distribute source-only wheel as fallback). With setuptools I would try something like this (untested):

from setuptools import setup, Extension
from Cython.Build import cythonize

setup(
    ext_modules=cythonize(
        [
            Extension(
                "twisted.internet._deferred_cython",
                sources=["src/twisted/internet/_deferred_base.py"],
            )
        ]
    )
)

Unfortunately I can't figure how one would do this with the current config format. I am particularly confused by the fact that there's no way to list which files an extension should have, or at least no documented way. My initial attempts resulted in every single .py file being compiled as an extension, which is probably not ideal :grin:

Any help would be appreciated.

[ofek]

Can you show examples of configuration that you have tried?

[joshua-auchincloss]

Appreciate the time to detail your use case, much appreciated.

As @ofek mentioned, a config reference would be helpful - if I'm understanding your use case properly though, your aim is to compile the python files only specified by what you declare in the configuration? At this time, there is only an exclude implementation; that being said I'm happy to implement / accept PRs if it's a needed feature 👍

[itamarst]

Yes, an explicit include config is what I would need, and ideally explicitly including and configuring per extension.

(It's a common use case for Python packages to have multiple Cython extensions, so the config format should probably be modeled using that abstract model. The current config model seems very global?)

[joshua-auchincloss]

Yes, an explicit include config is what I would need, and ideally explicitly including and configuring per extension.

Agreed - will set up a tracking issue for this one.

(It's a common use case for Python packages to have multiple Cython extensions, so the config format should probably be modeled using that abstract model. The current config model seems very global?)

Hmm, this one I support less but am open if there's a strong technical reason to support - I'm not in particular against this, but in those use cases I think it's a project design consideration vs how this library should function. I don't want to tell anyone else how to structure their projects, but IMO the best approach to needing multiple Cython extensions is to take a rust-style monorepo approach where each submodule has it's own pyproject.toml, or splitting components across repos. The opposite feels like an anti-pattern (specifically with hatch) where we explicitly define a project under one namespace.

[joshua-auchincloss]

Hey @itamarst - v0.6.0rc0 is released, feel free to try it out. Let me know if there are any issues with the build & will work to have the final v0.6.0 suit the needs of your use case.

Based on the above, you'll want a config like:

# hatch.toml

[build.targets.wheel]
macos-max-compat = false
packages = ["twisted"]

[build.hooks.cython]
dependencies = [
  "hatch-cython>=0.6.0rc0"
]

[build.hooks.cython.options]
src = "twisted"

[build.hooks.cython.options.files]
aliases = {"twisted.internet._deferred_base" = "twisted.internet._deferred_cython"}
targets = ["*/internet/_deferred_base.py"]