HNHacker News
TopNewBestAskShowJobs

sealedservant

11 karma · joined June 11, 2024

submissionscomments
sealedservant··on Python Has Too Many Package Managers
My problem with pip-tools is this:

# pip-tools dependencies

dependencies = [

  # direct dependencies

  "build >= 1.0.0",

  "click >= 8",

  "pip >= 22.2",

  "pyproject_hooks",

  "tomli; python_version < '3.11'",

  # indirect dependencies

  "setuptools", # typically needed when pip-tools invokes setup.py

  "wheel", # pip plugin needed by pip-tools
]

pip is nice since it comes out of the box with Python. setuptools used to but now it's gone.

The dependency explosion is a huge problem for a lot of people trying to lockdown the security and maintainability of their codebases. I think that's why a lot of people are rallying around Astral's projects like uv and ruff... they do so many things and they do them well.

sealedservant··on Python Has Too Many Package Managers
> And I've done the last one, converted all packages to wheels

Did this require just downloading the packages again from the requirements.txt, or can pip do this? That could help me out quite a bit...

sealedservant··on Python Has Too Many Package Managers
Ah, that's news to me! Updated previous comment for accuracy.

I mostly use pipx these days for stuff I need on the PATH.

sealedservant··on Python Has Too Many Package Managers
Virtual environments are cool, and necessary, but at the same time, they are incredibly limited and I always get frustrated at the lack of features they should have. They are too fragile.

Nuking a whole venv when you mess up isn't really efficient.

They aren't portable. You need to package up your editable project for an offline system? Too bad, virtual environments use hardcoded paths and symlinks that will be broken when you try.

Want to convert the packages in your venv back to .tar.gz or wheels? There's no way to do that either.

sealedservant··on Python Has Too Many Package Managers
I concur and I also think that there are too many build backends.

pdm is my current favorite package manager. It is fully PEP-compliant and the lockfile generation is nice. I wouldn't call hatch a package manager because I don't think it can make lockfiles.

uv is on my radar but it doesn't look ready for primetime yet. I saw they are building out a package management API with commands such as `uv add` and `uv remove`. Cross-platform lockfiles, editable installs, in-project .venv, and a baked-in build backend might be enough for me to make the switch. It's my pipe dream to get the full build/install/publish workflow down to a single static binary with no dependencies.

Anna-Lee Popkes has an awesome comparison of the available package managers [0] complete with handy Venn diagrams.

The pyOpenSci team has another nice comparison of the available build backends [1].

[0] https://alpopkes.com/posts/python/packaging_tools/

[1] https://www.pyopensci.org/python-package-guide/package-struc...