Good to see attention being drawn to this clever project. It doesn't fix performance issues with Pip, per se, but it does demonstrate that a lot of "bootstrapping" issues are really just a matter of keeping the tools in a separate environment - it's not at all necessary to write them in a different programming language just to isolate them. Pip has supported installing "cross-environment" for a while now, but it's awkward and hacky; Pipx puts a nice wrapper over that while also managing some virtual environments.
One of my main projects, Paper, draws heavy inspiration from Pipx's design. The goal, essentially, is to fix the major architectural issues with Pip (by starting over), while also integrating Pipx functionality (managing environments and installing packages "as applications" into them). I'm hoping I'll be able to do an overview of the design as part of my blog post series within the month.
One major downside with Pipx is that it deliberately refuses to install "library" packages (its definition: no console entry points are defined in the metadata). You can have Pipx create a "dummy" environment for a trivial "application", and then have it run Pip in that environment (either via `pipx inject` or `pipx runpip`), but both are awkward. I instead set up some wrappers (discussed in my recent post: https://zahlman.github.io/posts/2025/01/07/python-packaging-...) that just let me use the Pipx-provisioned copy of Pip globally. This allows you to create new venvs `--without-pip` - taking about 50 milliseconds on my 10-year-old machine (with an SSD), rather than over 3 seconds.
One of my main projects, Paper, draws heavy inspiration from Pipx's design. The goal, essentially, is to fix the major architectural issues with Pip (by starting over), while also integrating Pipx functionality (managing environments and installing packages "as applications" into them). I'm hoping I'll be able to do an overview of the design as part of my blog post series within the month.
One major downside with Pipx is that it deliberately refuses to install "library" packages (its definition: no console entry points are defined in the metadata). You can have Pipx create a "dummy" environment for a trivial "application", and then have it run Pip in that environment (either via `pipx inject` or `pipx runpip`), but both are awkward. I instead set up some wrappers (discussed in my recent post: https://zahlman.github.io/posts/2025/01/07/python-packaging-...) that just let me use the Pipx-provisioned copy of Pip globally. This allows you to create new venvs `--without-pip` - taking about 50 milliseconds on my 10-year-old machine (with an SSD), rather than over 3 seconds.