Pip install Postgres – no Docker/Brew/apt(github.com)
github.com
Pip install Postgres – no Docker/Brew/apt
https://github.com/leontrolski/postgresql-testing
5 comments
Some discussion on (ab?)using pypi to distribute binaries - https://discuss.python.org/t/use-of-pypi-as-a-generic-storag...
Wherever you fall on that debate (I have my opinions but they are not strongly held), a bigger red flag here for me is the `pip install ...` opener. The fact they later have a `uvx ...` example in the docs just makes defaulting to pip even worse.
As that comment mentions:
> 5 years ago [...] Python packaging was a big mess.
> Today [...] I think Python's packaging story has never been stronger.
Poetry, & later Uv, are essential & invaluable milestones in that revolutionary story; Pip is terrible software & should be left in the past.
As that comment mentions:
> 5 years ago [...] Python packaging was a big mess.
> Today [...] I think Python's packaging story has never been stronger.
Poetry, & later Uv, are essential & invaluable milestones in that revolutionary story; Pip is terrible software & should be left in the past.
> Poetry, & later Uv, are essential & invaluable milestones in that revolutionary story; Pip is terrible software & should be left in the past.
The comparison to other programs is missing the point of why pip is terrible. For that matter, last I checked Poetry relied on either vendored pip or something very much like it to do the actual package installation.
If you like workflows dictated by all-in-one tools, go for it. Don't force it on me. Some of us still see great value in the Unix philosophy.
The real problem is that pip doesn't even do a good job of its "one thing" (the actual package installation). It barely understands caching, has insecure and confusing default behaviours stemming from nigh-unfixable legacy issues, doesn't know how to inspect the installation environment properly (therefore relying on ugly hacks to install cross-environment at all), vendors a bunch of stuff it barely uses and often doesn't really need, and is overall horribly architected.
The comparison to other programs is missing the point of why pip is terrible. For that matter, last I checked Poetry relied on either vendored pip or something very much like it to do the actual package installation.
If you like workflows dictated by all-in-one tools, go for it. Don't force it on me. Some of us still see great value in the Unix philosophy.
The real problem is that pip doesn't even do a good job of its "one thing" (the actual package installation). It barely understands caching, has insecure and confusing default behaviours stemming from nigh-unfixable legacy issues, doesn't know how to inspect the installation environment properly (therefore relying on ugly hacks to install cross-environment at all), vendors a bunch of stuff it barely uses and often doesn't really need, and is overall horribly architected.
I get you on unix philosophy (I'm not into it myself but I respect those who want that) but uv, for all its extra features, does actually do that particular "one thing" a lot better than pip.
You've summarised many of pip's internally problems well - there's also the lack of any attempt at proper manifest management. This is partially an ecosystem problem (pre-PEP518), but the tools inform the specs as much as the specs inform the tools.
I think there's also a reasonable argument to be made that uv only does one thing, & that the big problems in this space before was that python required using 3 tools to awkwardly collaborate to get one thing done. That one thing is dependency management: pip to pull them, venv to load them, pyenv to pull & load one of them (the interpreter).
You've summarised many of pip's internally problems well - there's also the lack of any attempt at proper manifest management. This is partially an ecosystem problem (pre-PEP518), but the tools inform the specs as much as the specs inform the tools.
I think there's also a reasonable argument to be made that uv only does one thing, & that the big problems in this space before was that python required using 3 tools to awkwardly collaborate to get one thing done. That one thing is dependency management: pip to pull them, venv to load them, pyenv to pull & load one of them (the interpreter).
pyenv is a wrapper for something that experienced pip+venv users would find trivial. If you use uv, meanwhile, that is also wrapping venv. It's integrating those tasks under one command prefix, which is the main thing I don't like.
The other thing I don't like is having tens of megs of opaque compiled binary (that doesn't provide a useful library) when properly designed Python would perform more than acceptably for common use cases (tons of this is I/O-bound; a proper cache lets you just recursively hardlink a directory tree instead of unpacking an archive file; the bytecode compilation is implemented in C and could be parallelized with `multiprocess` as long as you don't require binary-level reproducibility for Python bytecode; etc.)
The other thing I don't like is having tens of megs of opaque compiled binary (that doesn't provide a useful library) when properly designed Python would perform more than acceptably for common use cases (tons of this is I/O-bound; a proper cache lets you just recursively hardlink a directory tree instead of unpacking an archive file; the bytecode compilation is implemented in C and could be parallelized with `multiprocess` as long as you don't require binary-level reproducibility for Python bytecode; etc.)
Python world has moved to uv from pip, at least that's the direction.
Category error
why would you use the worst package manager instead of the better ones?