Recent searches
Search options
So there was a time when if you wanted compiled extensions in your Python project, but you didn't want to install a _package_, you'd have a setup.py, and you'd do:
python setup.py build_ext -i
Thing is, calling setup.py directly is now deprecated.
Is there any way to do the above that isn't calling setup.py? I've seen a suggestion of calling setuptools internal API directly, which ... ok, I guess. But wondering what people do in practice. Just make everything compiled an installable package?
"pip install -e ." is not equivalent! E.g. if you're using setuptools-rust it will build in non-release mode.
EDIT: To clarify, what are people using setuptools doing? I understand other tools may have options for this.
I went and tried "setup.py build_ext -i" and... it's not deprecated? No warnings, anyway, still works fine. So just gonna go with it still.
@itamarst "No, setup.py and Setuptools are not deprecated." https://packaging.python.org/en/latest/discussions/setup-py-deprecated/
@itamarst "Custom build steps that for example either overwrite existing steps such as build_py, build_ext, and bdist_wheel or add new build steps are not deprecated."
@hynek @glyph @itamarst Way back when the wheel format was being introduced and PyPA had just started morphing into its current incarnation, we did a developer panel at PyCon US. The panel subtitle was "'./setup.py *install*' must die" (emphasis added). That subcommand qualification is often lost when folks discuss the status and future of `setup.py`, even though build processes frequently get complicated enough that they *can't* be reasonably expressed in a declarative form.
@ancoghlan @hynek @glyph @itamarst There's additional confusion because the setuptools project want to deprecate some things (like running setup.py build_ext -i) that the packaging community don't have a standardised replacement for.
@pfmoore Ah, I had wondered why that page was so insistent that *all* subcommands were deprecated, not just the package distribution related ones. The *project* wanting to drop that invocation method explains that.
I suspect they will find they need to add their own backend-specific CLI to truly get rid of all the potential invocations (like build_ext). (flit/pdm/hatch/etc have their own dedicated CLIs, enscons/meson-python/etc correspond to existing build tool CLIs)
@glyph Right, but they want to deprecate "python setup.py" commands, AIUI.