Agreed! The good news is that it's slowly getting better: just yesterday[1], setuptools added support for PEP 660[2], which removes one of the last remaining reasons to use a `setup.py` instead of a fully declarative `pyproject.toml`.
Edit: Also, just to qualify: this is a consistent problem across packaging ecosystems. Even system package managers (reasonably!) allow custom code during installation, e.g. to add service hooks and update locale files.
[1]: https://twitter.com/juanluisback/status/1557734536586625025
Perhaps spit a scary sounding security warning for all packages which use a setup.py?
This would be nice, but there's probably too many practical barriers to this. For example, you can't (easily) replace `setup.py`'s dynamism for packages that contain native packages: they need to be able to spawn compilers, etc. and do so in ways that are hard to describe declaratively.
We probably don't want to provide a security warning on every native non-wheel package, so that's a no-go for the time being.
In terms of hooks, audit hooks and events[1] get us some of the way there. But they can be circumvented as well; I wouldn't rely on them for untrusted code.
Wheels are solving that problem, but it's likely going to be many years before warning about `setup.py` is reasonable and not disruptive to the majority of legitimate users.
And some pyproject.toml features are still experimental per the setuptools docs, so I'm not sure which method to choose for our internal projects.
I'm glad the setuptools/pip/Python devs are cleaning up the packaging situation though. pyproject.toml seems perfect, when it becomes ready.
[1] https://setuptools.pypa.io/en/latest/userguide/pyproject_con...
(But this doesn't matter for packaging purposes, since setuptools is also not included in the base distribution, but does include TOML support.)
I actually wrote a Python tool for downloading binary releases from GitHub and Gitea and wrote a “builder” module that can be used in a pyproject file to tell it to download an arbitrary binary and run some commands.
Here’s an example in action: https://github.com/IamTheFij/release-gitter/tree/main/sample...
In Rust it's "worst", you can run custom code at compile time. But IMO the issue is that we are optimizing everything for convenience at the cost of security. The compile/install custom code wouldn't be an problem if each dependencies was pinned and audited.
PyPI requiring 2 factors authentication on "popular" projects will help, but this will not replace the needs for auditing, vetting and pinning.
What is ridiculous is that users have no way of restricting what packages can run on a fine-grained level, at both build time and runtime.
We should fix that problem. If we do, then we could make computing a lot safer.
Disclaimer: I'm working on that problem.