-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement declarative ext-modules
in pyproject.toml
("experimental")
#4568
Conversation
What this PR does not do is automatic detection as suggested by @jaraco in #2220 (comment). I feel that this would be the next step with a separated discussion/implementation. See #4569. |
44c2f3e
to
4f238a5
Compare
@jaraco, would it be OK if we experiment with allowing binary extensions to be defined in |
SGTM |
@abravalheri personally, I still like using |
@abravalheri have you looked into interfaced suggested by https://ofek.dev/extensionlib/? Also, there's an interesting structure https://github.com/joshua-auchincloss/hatch-cython#usage. If some of those bits look good, perhaps it's worth gravitating towards those. OTOH, bear in mind that the PyPA adoption has been postponed: https://mail.python.org/archives/list/pypa-committers@python.org/thread/H76Q6OO5TFHLR2IICXRRJ5ZHEPBPUVR7/. |
How would this work with SWIG? |
I don't want to do anything fancy here, simply translate the configuration that already exists in setuptools and that people are already used to. I had a look on The approach I am following is very similar to the same one implemented in The interface implemented in this PR will be friendly to existing setuptools users and help with porting. Users will be able to write the equivalent of static |
In previous discussions in the setuptools repository, it has been established that the y vision is to not maintain 2 different formats. That is why I think we should not implement new features on Regarding g the cluttering of In the future, we might explore other convention-over-configuration approaches, but this PR can establish the foundation that we can add those on top. |
4f238a5
to
592d089
Compare
🎉 |
@abravalheri I was thinking whether I could apply this to https://github.com/aio-libs/multidict somehow (the C-extensions are written in pure C, not Cython) and realized that one dynamic bit present is OS-dependent CFLAGS: https://github.com/aio-libs/multidict/blob/f3876fd/setup.py#L12-L30. Do you think a future setuptools version would be able to accommodate that? |
We possibly can implement some bits of dynamic functionality on top of the existing static configuration. But we have to think about a proposal that makes sense. I saw the link you sent on https://github.com/joshua-auchincloss/hatch-cython#usage, and my first impressions where:
compile_args = [
# single string
"-v",
# by platform
{ platforms = ["linux", "darwin"], arg = "-Wcpp" },
# by platform & arch
{ platforms = "darwin", arch = "x86_64", arg = "-arch x86_64" },
{ platforms = ["darwin"], arch = "arm64", arg = "-arch arm64" },
# with pep508 markers
{ platforms = ["darwin"], arch = "x86_64", arg = "-I/usr/local/opt/llvm/include", depends_path = true, marker = "python_version <= '3.10'" },
] If feels pretty much a re-implementation of a classical What I want to avoid is people writing I think adding dynamic capability to integrate better with plugins and 3rd-party libraries makes a lot of sense. But hand-picked customisations may just make more sense written in Python. Footnotes
|
Summary of changes
Implement declarative definition of the equivalent of
setup(ext_modules=[...])
viapyproject.toml
:setuptools/config/_apply_pyprojecttoml.py
to transform configs frompyproject.toml
intosetuptools.Extension
object.Closes #2220 (the original issue suggests
setup.cfg
, this PR implements the capability inpyproject.toml
, but that should be fine)./crossref cython/cython#6338
/cc @webknjaz
Pull Request Checklist
newsfragments/
.(See documentation for details)