“import json” is the kind of thing which requires picking and installing libraries in batteries-not-included languages, and it’s just one of many modules which are in the standard library. That’s not a compelling basis for large projects but over the years I’ve shipped a ton of useful production code which never needed more than the stdlib and thus spent no time at all thinking about deployment or security patching.
Also, it’s not the 2000s any more. Using venv to isolate application installs is not very hard anymore and there have been decent package managers for a long time.
“broken” is hyperbole. It works fine for millions of people every day. If you have some specific scenarios where you want it be better, it’s better to say those rather than just complain about an open source project.
> Millions of people put it into Docker, or they just deal with it and you see the results with tons of Stackoverflow questions
Arrogantly wrong.
I've coded in Python for almost 20 years. Many of those years I've had it as my primary language at work.
2024 was the first year I actually needed a virtualenv. Before that, I'd happily use pip to install whatever I want, and never had a version conflict that caused problems.
I often encounter junior folks who default to using a virtualenv, not because they need to, but because they've been brainwashed into believing that "you're doing it wrong if you don't use one".
>2024 was the first year I actually needed a virtualenv. Before that, I'd happily use pip to install whatever I want, and never had a version conflict that caused problems.
Okay I'll bite: how did you deal with situations where you needed to work on two different projects that required different versions of the same dependency?
I was talking about pip, not venv. I don't use venv either, not because I think it's a bad idea but because I can't be bothered. Stuff does end up conflicting unless I use Docker (lol) or uv.
Because I went to the official pip "getting started" docs and did exactly what it says? It's bad even in venv though, like not managing your requirements.txt or installing conflicting stuff. The web is full of questions about this, with answers that involve installing some other thing.
but yes, pip predates the paradigm of package managers managing your dependency file instead of you managing your dependency file and then invoking the package manager
The rest of the thread makes it clear that you expect a "package manager" to do more things than Pip does.
Pip is focused on installing the packages, not really "managing" them. The problem is that there are quite a few different takes on what "management" should entail. That's where all the alternatives are coming from.
Whichever you call it, at the end of the day it's more common to encounter dep problems in Python than with NodeJS, Rust, etc.
But also, ignoring things pip isn't meant to do like version management and just focusing on installing, pip's default of installing to some unclear system location was always confusing, particularly when Py2 vs 3 was a thing.
I would like to try uv, but I don't find Poetry that bad for dependency resolution times. If I have to wait 2 minutes once a week it's not the end of the world. Maybe if you're constantly installing new things that are tough to resolve it's an issue.
It's not the end of the world, but it's annoying. I used to work at a place that had a huge monorepo with tons of dependencies. Poetry would sit there grinding away for 4 or 5 minutes. With smaller projects, I agree it's not much of an issue. But, uv has other cool features and it's super snappy!
I'm not arguing on venv to isolate installs, I'm saying that relying on Python coming from UNIX-like OSes is close to impossible for, at least web related projects. I.e. Ansible does a lot [in terms of what code it generates] to keep itself compatible with whatever Python3 versions it may find on systems ( remote hosts )
Also, it’s not the 2000s any more. Using venv to isolate application installs is not very hard anymore and there have been decent package managers for a long time.