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 maybe you want to look at NumPy or SciPy. We are using meson but other folks are using other solutions too like https://scikit-build.readthedocs.io/en/latest/usage.html
@melissawm I should look at that, yeah, but the question isn't really what tool should I use in my own code project.
Rather, it's how can I support this ability in a dockerizing template that's supposed to work with random projects' build systems that likely use setuptools.
(Right now the template uses "setup.py build_ext -i".)
@itamarst I would normally aim for a package that encapsulates this at build time, yea. If I really wanted to avoid that, I'd probably hold my nose and use the deprecated command, or write my own automation to drive the relevant compilation. In practice I've only done the former in production, but I *have* done the latter for examples in my 'playground' where I whittle down reproducers or write little demos/prototypes
@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.