I think I can say this more concisely:
- For a lot of existing, popular workflows, the first operation is “create a venv with a specific interpreter version”
- But right now, there’s a bunch of faffing around needed before you can create a venv, and it’s a huge roadblock for new users (install conda / homebrew / python.org / which do I use / do I have the right interpreter installed / …)
- With a tiny bit of infrastructure, we could make “create a venv with a specific interpreter version” a boring solved problem that just works with no human intervention
All these other tools are genuinely awesome at what they do. They solve all kinds of problems that I’m not talking about here. But they also add a ton of complexity that is really unnecessary for this specific use case.
No-one expects venvs to be listed in the registery or support upgrading.
The problem with GUI support on macOS thing is definitely an issue, but it doesn’t sound like it’s anything intrinsically impossible, just a bug that would need to be fixed as part of the work on this.
I hear that. I don’t have the energy to do it either myself :-). But IMO this is absolutely something that should have official support from the core team. It’s a practical plan, with well-defined scope, that that would eliminate a major pain point for a wide variety of different workflows and unlock new possibilities. I’d even be willing to wager that if we did start shipping these binaries, then they’d end up with more downloads than any of the current official installers.