I'm developing PAPER (the Python Application, Package and Environment wRangler, a Python package installer), and will soon return to bbbb (the Bare-Bones Build Backend, a build backend for Python packages).
PAPER is designed from the ground up to avoid Pip design mistakes, directly taking advantage of new standards while also offering Pipx-like functionality. Unlike uv, Poetry etc., PAPER is not a project manager or workflow tool; it installs the packages that you tell it to (and their dependencies), when/where/because you do. It's entirely user-focused, and usefulness for developers is treated as mostly incidental. (However, it can of course form a useful part of a proper development toolchain.)
It's not in a publicly-usable state yet, but these are the main design principles I'm working from:
* It's designed from the ground up to provide a programmatic API and to install cross-environment (in fact, you're only expected to install in its own environment in order to provide plugins). The API is provided by a separate wheel; other projects can explicitly cite that as a dependency and don't have to `subprocess.call` to a CLI.
* Size and performance are paramount. (Much of Pip's slow performance on smaller tasks is due to its size). I'm aiming for ~1MB total disk footprint for the base installation (compare ~10-15 for Pip, which is often multiplied across several environments; ~35 for uv). Dependencies are very carefully considered; installations are cached as much as possible (and hard-linked when possible, like with uv); etc.
* The program bootstraps itself as a zipapp that pre-loads the program's own cache before having it install itself from its own wheel (within that cache). This entails that there aren't any "hidden" vendored dependencies; anything that ends up bundled with PAPER can immediately be installed with PAPER, without an Internet connection.
* Non-essential functionality can be provided later by simply installing optional dependencies. The default is sufficient for the program to install wheels with minimal feedback.
* The CLI is built around separate hyphenated commands rather than sub-commands, for simpler implementation and better tab-completion. Commands are aimed at offering somewhat finer-grained control while keeping simple use cases simple.
bbbb is largely inspired by Flit, but is also intended to support projects with non-Python code, and doesn't enforce distributions with a single top-level import package. It uses the same split between a core package and a full development package, except the core package is treated as default. It's designed to be even more minimal than flit-core, and in fact can only build wheels by itself (dynamically pulling in the dev package if asked to make an sdist).
The goal is to minimize download footprint and maximize modularity when end users download an sdist and want to make a wheel from it (for example, implicitly via an installer). Users will declare the dev package as the build system in pyproject.toml, and may even declare it as an in-tree backend which will then be automatically added to the sdist. So people who (for some reason - perhaps to satisfy Linux distro maintainers) want to distribute an sdist for pure Python code, won't need any build-time dependencies at all.
Building non-Python code in bbbb, as well as customizing sdist contents and metadata (beyond what's directly supported), works by hooking into arbitrary Python code. Unlike the setup.py of Setuptools, the code can have custom name and locations specified in pyproject.toml, and it has specific and narrow purpose. I.e.: it's not part of implementing a class framework to power a now-deprecated custom CLI; it only implements compilation/metadata creation/manifest filtering - and does so with a much simpler, more direct API. You're meant to build upon this with additional support libraries (e.g. to locate compilers on the user's system) - again, modularity is key - that are separately listed as build-time dependencies.
I'm trying to make simple, elegant, pure-Python tools that complement each other and respect (my understanding of) modern Python packaging standards and their underlying goals. A developer could end up with a toolchain that looks like: PAPER, bbbb, build (the reference build frontend provided by PyPA), cookiecutter (or similar - for setting up new projects), twine (the default uploader), and some shell scripts - for things like "install dependencies with PAPER in a new environment and then add a .pth file for the current project to that environment". (And if you like linters and typecheckers, I certainly won't stop you from using them.)