While I like, support and adopted PEP-518 on several projects, even with known costs, I never fully removed the setup.py, for two big reasons: avoiding breaking lots of older systems and second: keeping editable installs working. I do see the editable installs as key setups for easing the process of receiving contributions, especially new or occasional ones.
Was anyone able to build some stats regarding how many of top~100 projects do no longer have a setup.py in their SCM? I tried to dig a little bit around most of the python projects I used in the last decade and I failed to spot even one that dropped setup.py
My impression was that effective mainstream drop of setup.py would realistically happen around 2022, when toolsets would have time to mature enough and the need to support more or less older tools/platforms would not so pressing any more.
Is there something deeply wrong with keeping a minimalist setup.py like below?
import setuptools
if __name__ == "__main__":
setuptools.setup(
use_scm_version=True, setup_requires=["setuptools_scm"],
)
I don’t think anyone will drop setup.py using setuptools who wants editable installes (whcih is almost anyone). Things might change once we have a PEP-517 for editable installs. In the meantime having a minimalist setup is ok.
FWIW pip already “shims” setup.py for PEP-517 builds if it does not exist. This wouldn’t be a problem if it does the same for editables. Although I understand the position of not wanting to invest into the current behaviour and wait for PEP 517 instead.
I also mentioned a while ago that Setuptools could implement a __main__.py to offer the same functionality, so people can drop their shims and use python -m setuptools [command] instead. But the proposal never got any interest and went nowhere.
(And I’ll shamelessly plug my Setl project here again, which handles editable installs in the lack of setup.py perfectly ) https://github.com/uranusjr/setl
I misattributed the behaviour. It’s Seruptools’s PEP 517 hooks doing this automatically (so pip gets that for any Setuptools projects running those hooks).
Many mainstream projects I use have extension modules, which most definitely require the setup.py (or some other way of build-time compilation: pendulum uses a separate build script using distutils with poetry).
Also, building the package for distribution (ie python setup.py sdist bdist_wheel) obviously still needs setup.py, unless another packaging backend is used to generate the distributables.
The rsa project has also recently removed setup.py. I think it is mainstream because its a dependency of the AWS CLI and some of the Google API libraries.
It is practical to include at least a stub setup.py especially for pip install -e . (The enscons stub setup.py calls the develop target in your SConstruct). It is certainly not a moral question.
Haha!, listing aws-cli as an example made me had a big laugh, mainly because they decided to stop publishing to pypi. The https://github.com/aws/aws-cli/issues/4947 thread is a funny read.
Based on experience, I would list aws-cli project (boto* included) as an example about what should never do about python packaging.
Do your criticisms extend to the rsa package? That was the one I wanted to draw attention to as an example. I only mentioned the packages that depend upon it as evidence it is mainstream.
I’m not involved in that project, though I am in the Azure equivalent, and those are all very legitimate reasons.
Pip is not an application installer, and PyPI is not an application repository, and system CPython installs are barely an application runtime.
I know this seems off topic for this thread, but I think it’s important context. What we’re talking about here is just never going to fix full application installs, whether we want it to or not.
Our tools are for Python libraries, anything even mildly complex is going to have to use more than one tool to achieve what it needs. There is no single winner, and expecting/demanding one is not helpful for those who look in on our community.
) 
I’m enjoying using my own enscons