How does PDM manage C extensions or other non-Python code?

[lazarillo]

I am starting to use PDM and enjoying it.

I am trying to make this the method our whole team uses. They are used to virtual environments, conda, etc. They were concerned that things with c extensions like numpy or scipy wouldn't work. I already have them installed and showed that it wasn't a problem.

But it got me thinking: this is because they are already wheels (pre-compiled binaries upon install). What about libraries and packages that have dependencies beyond Python, but which need to be compiled by source. I don't understand how PDM handles this. I have to admit, I don't fully understand how Conda or venv does, either. I mean, I understand that the virtual environments are not assisting with the install at all. But at some level, there is a call to gcc or clang or some other tool that is needed to compile, and this compiled code is saved somewhere. How is all of that managed in PDM? Does it work properly? Is there any concern I should have with non-wheel software when using PDM?

[pawamoy]

Here's a paragraph about that in the docs: https://pdm.fming.dev/pyproject/tool-pdm/#build-c-extensions
I'll let @frostming or someone else expand on the subject, as I've never used C extensions.

[lazarillo]

Yeah, I read that. It tells me what I need to do within the code. But it does not tell me what is actually happening. 😬

[frostming]

pdm just calls setuptools to build C extensions, you define the extensions as described and it will invoke underlying C compilers(gcc or MSVC) to compile a module.

[sanmai-NL]

@pawamoy Your hyperlink is now broken.

[pawamoy]

Yup, can't find a new working link though.

[frostming]

https://backend.pdm-project.org/hooks/#call-setup-function-to-build-extensions

[frostming]

i am on a mobile phone, you can read PEP 517 about how a package manager builds wheels from source.