Comment by zahlman

> avoiding chicken-and-egg problems by writing the tool for managing a programming language environment in a different language

I've heard this a lot, but I don't really understand the use case. It seems that people want to do development in Python, want to install and manage third-party Python packages, and know how to use command-line tools, but somehow they don't already have Python installed and would find it challenging to install directly? Building from source on Linux is a standard "get dev packages from the system package manager; configure, make and install" procedure that I've done many times (yes, putting it beside the system Python could break things, but you can trivially set an alternate install prefix, and anyway the system Python will usually be a version that meets the basic needs of most developers). Installing on Windows is a standard Windows installer experience.

Aside from that, people seem to imagine "chicken-and-egg" scenarios with pip making itself available in the environment. But this is a thoroughly (if inefficiently) solved problem. First off, for almost three years now pip has been able to install cross-environment (albeit with an ugly hack; I detail some of this in https://zahlman.github.io/posts/2025/01/07/python-packaging-...). Second, the standard library `venv` defaults to bootstrapping pip into new environments — taking advantage of the fact that pre-built Python packages are zip archives, and that Python has a protocol for running code from zip archives, which the pip package implements.

The real bootstrapping issue I've heard about is https://github.com/pypa/packaging-problems/issues/342 , but this affects very few people — basically, Linux distro maintainers who want to "build" an entire Python toolchain "from source" even though it's all Python code that the runtime could bytecode-compile on demand anyway.