Note this would break python.buildEnv / python.withPackages. I suppose that is fine for this Python because its not intended for use with packages anyway.

Maybe renaming pythonMinimal to bootstrappingPython would be better, to indicate it isn't just a regular python you should use?

I have every intention to use the minimal python with packages.

Me and @flokli spent a bit of time around last Nixcon experimenting with the Python test driver and pystemd.
I haven't touched this effort in a while but that's still something I'd like to accomplish.

Your intentions to use it may not match with the package maintainter's intentions in packaging it :P (so maybe there is a need for a minimal python, and a bootstrapping python, like @LnL7 was suggesting.)

@grahamc Well, I was the one who created python3Minimal for exactly that kind of purpose.

Another thing I'd like to see it used for is the minimal installer.

Oh 🙃

I recall @LnL7 mentioning something about copying over/vendoring a bootstrappingPython, so the python.buildEnv changes don't affect the glibc build.

With @grahamc's change to the python3 expression I think we could add a bootstrapPython like this:

bootstrappingPython = python3Minimal.override { includeSiteCustomize = false; };

which still makes it possible to use python3Minimal with packages without causing spurious mass-rebuilds.

Obviously I'd like @LnL7 to chime in on this.

See #77610 (comment).

For bootstrapping llvm I added a minimal python/boot.nix stripped as much as possible. Making the expression completely separate introduces a little bit of duplication but has the advantage that the regular expression, setup-hook, etc. can be changed freely without having to re-bootstrap.

Note I am looking into actually patching site.py instead of using sitecustomize.py because sitecustomize.py is loaded too late (#79702 (comment)).

For now I would like to go ahead with it. If we find the need to build packages with it, we create a separate pythonBoot.