7 ms·

Pip install Postgres – no Docker/Brew/apt

29 points by leontrolski 2mo ago

leontrolski 2mo ago
Some discussion on (ab?)using pypi to distribute binaries - https://discuss.python.org/t/use-of-pypi-as-a-generic-storage-platform-for-binaries/106044/57 https://discuss.python.org/t/use-of-pypi-as-a-generic-storag...
- lucideer 2mo ago
  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.
  - zahlman 2mo ago
    > 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.
    - lucideer 2mo ago
      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).
      - zahlman 2mo ago
        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.)
wewewedxfgdf 2mo ago
Python world has moved to uv from pip, at least that's the direction.
- formerly_proven 2mo ago
  Category error
deleted 2mo ago
[deleted]
hmokiguess 2mo ago
[flagged]
PunchyHamster 2mo ago
why would you use the worst package manager instead of the better ones?
doadfda 2mo ago
[dead]

29 points by leontrolski 2mo ago

Some discussion on (ab?)using pypi to distribute binaries - https://discuss.python.org/t/use-of-pypi-as-a-generic-storage-platform-for-binaries/106044/57 https://discuss.python.org/t/use-of-pypi-as-a-generic-storag...

lucideer 2mo ago
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.
- zahlman 2mo ago
  > 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.
  - lucideer 2mo ago
    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).
    - zahlman 2mo ago
      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.)

wewewedxfgdf 2mo ago

Python world has moved to uv from pip, at least that's the direction.

formerly_proven 2mo ago
Category error

deleted 2mo ago

[deleted]

hmokiguess 2mo ago

[flagged]

PunchyHamster 2mo ago

why would you use the worst package manager instead of the better ones?

doadfda 2mo ago

[dead]