For the last 20 years that has been the mantra. Some X "solves" all the problems.
Except it doesn't. It just creates another X that is popular for a while, and doesn't somehow retroactively "fix" all the chaotic projects that are a nightmare to install and upgrade. Yes, I understand people like Python. Yes, I understand the LLM bros love it. But in a real production environment, for real applications, you still want to avoid it because it isn't particularly easy to create robust systems for industrial use. You may survive if you can contain the madness in a datacenter somewhere and have people babysit it.
Solving it at least involves the Python maintainers making a choice, integrating it into the Python binary and sticking to it. At least. But that requires possibly annoying some people until a) whatever solution becomes mature and b) people get over it.
I've ignored the trends and just used the bog standard requirements.txt with pip and a virtualenv and have had no problems in the past 10+ years. Either way, you always want to catch production deploys if something breaks.
That is only true if you never reexamine the universality of your statement. I promise that it is possible to "solve" the mess that was Python's ecosystem, that uv has largely done so, and that your preconceptions are holding you back from taking advantage of it.
Here's the thing: there has never been a lack of people who have declared this problem as solved in the 20 or so years since Python started Poking its way into my professional life. (And for about 12-13 years before that I could gladly ignore it since nobody did much of anything in it). People have said this since the days of the Blackberry.
Multiple times people have explained why they think whatever they are madly in love with now is the definitive solution. And none of those times, over those couple of decades did it turn out to be true.
I understand that you are enthusiastic about things. I get it. But perhaps you might understand that some people actually need to see things stick before they declare a winner? I'm not big on wishful thinking.
I would take a look at uv adoption. That's what makes it different. It nails everything that all the other tools have done and it does it fast. So it's been what people have been using for a while now. Even poetry never seemed to get this ubiquitous of support.
I'm not saying uv isn't catching on. I'm saying most Python software still doesn't use it and for meaningfully complete adoption to happen, a solution has to be the default solution, preferably included in the standard distributions of the language.
Every single language enthusiast says that some of the biggest codebases in the world are whatever their favorite major language is. And here's the thing: it is completely irrelevant whether the codebase is small or large. What counts is what it is like to use and maintain programs.
Python isn't the only language that has poor tooling. C/C++ is even bigger than Python in terms of established code base, and its tooling is nothing short of atrocious.
What helps is people realizing where tooling and production readiness should be. They can learn a lot from Rust and Go.
The it's big so therefore it must be right argument is nonsense. Worse yet: it is nonsense that excuses lack of real improvement.
> But in a real production environment, for real applications, you still want to avoid it because it isn't particularly easy to create robust systems for industrial use.
This is silly and seems to discount the massive Python codebases found in "real production environment"s throughout the tech industry and beyond, some of which are singlehandedly the codebases behind $1B+ ventures and, I'd wager, many of which are "robust" and fit for "industrial use" without babysitting just because they're Python.
(I get not liking a given language or its ecosystem, but I suspect I could rewrite the same reply for just about any of the top 10-ish most commonly used languages today.)
I can get that Pythons not for everyone, it certainly has its flaws and maybe uv is just another transient solution which will come and go and others have. I might disagree, but I can accept that. What I can't accept is the idea that it should be avoided for real production environments, which is frankly a bit ridiculous considering all the real applications and real production environments running on Python.
There’s still 20 years of projects using everything that became before uv. They didn’t upgrade the moment uv came into existence. Data science-land still uses other rubbish too.
> They didn’t upgrade the moment uv came into existence.
There's also projects that can't use `uv` because it doesn't like their current `requirements.txt`[0] and I have no bandwidth to try and figure out how to work around it.
[0] We have an install from `git+https` in there and it objects strongly for some reason. Internet searches have not revealed anything helpful.
Unrelated to uv but the problem with having a git ref in requirements.txt is that pip will treat it as a fixed version so it will strictly narrow the other dependencies it can resolve, which gets exceptionally difficult to reason about once that packages also loads a package from another git ref. Throwing everything into codeartifact (or equivalent on other clouds) is better longterm.
