Comment by vovavili
2 months ago
>I don't want to have virtual environments and learn what the difference between pip, poetry and uv is. I don't care. I just want to run the code.
So this is skill issue, the blog post. `uv run` and PEP 723 solved every single issue the author is describing.
While this is true, it is often stunning to me how long it took to get to `uv run`.
I have worked with Python on and off for 20+ years and I _always_ dreaded working with any code base that had external packages or a virtual environment.
`uv run` changed that and I migrated every code base at my last job to it. But it was too late for my personal stuff - I already converted or wrote net new code in Go.
I am on the fence about Python long term. I’ve always preferred typed languages and with the advent of LLM-assisted coding, that’s even more important for consistency.
Well said. I’m in the same boat of being on the fence about python. I’ve been burned too many times in the past.
And even if uv was perfectly solves all of our woes, it still seems worse than languages that solve packaging and deployment with a first-party built tools.
There’s only so much lipstick and makeup you can put on a pig…
Yeah, the difference between static and dynamically typed languages are massive with LLM coding, and the difference seems to me exponentially larger with larger codebases.
It's a UX issue. The author is correct — nobody cares about all the mumbo-jambo virtualenvs or whatever other techno-babble.
The user
just
wants
to run
the damn program.
> `uv run` and PEP 723 solved every single issue the author is describing.
PEP 723 eh? "Resolution: 08-Jan-2024"
Sure, so long as you somehow magically gain the knowledge to use uv, then you will have been able to have a normal, table-stakes experience for whole 2 years now. Yay, go Python ecosystem!
Is uv the default, officially recommended way to run Python? No? Remember to wave goodbye to all the users passing the language by.
I don't see your point. The kind of user who will struggle to type out `uv run` will find it even more difficult to type out `//usr/local/go/bin/go run "$0" "$@"; exit`. Neither approaches are the "default, officially recommended ways to run" scripts.
I strongly encourage you to read the article to acquire the context for the conversation before commenting, which is what I assume is happening here.
> Is uv the default, officially recommended way to run Python? No? Remember to wave goodbye to all the users passing the language by.
uv was invented basically yesterday. But it is becoming the default faster than any tool I've ever seen.
So I'd say: Yes - it is, effectively, the default now.
> Is uv the default, officially recommended way to run Python?
Yes, seems like it is de facto default, officially recommended way.
Is it officially recommended? I don't see it listed on PyPA's Tool Recommendations [0] and Project Summaries [1] pages.
[0] https://packaging.python.org/en/latest/guides/tool-recommend... [1] https://packaging.python.org/en/latest/key_projects/
> The user just wants to run the damn program.
I don't agree, the user wants to run the program in a way the user wants to, but is frustrated when it doesn't.
If all dependencies were installed on the machine the script would run no problem. I have some scripts with dependencies that are installed on the system.
The author writes:
> The built in tooling within the go ecosystem is another large selling point. We don't need a .pyproject or package.json to configure ad-hoc formatting and linters, backed by pipelines to ensure consistency.
Maybe shebangs is not the solution to that problem? It's a convenience to run scripts as executable, but the user is supposed to setup the environment. Then he continues to explain that go has a great stdlib which makes it perfect for scripting. This is the reason I usually reach for python for complex scripts, the stdlib is big enough to solve most my problems.
Now that node includes sqlite the choice isn't as easy, but I wouldn't be pissed at node and javascript if I have to setup the environment to make sure the script runs. I understand how it runs, where it gets the dependencies. If I forget to run `npm i` before running the scripts that's my error, I prefer errors that remind me of my stupidity over magic.
>Sure, so long as you somehow magically gain the knowledge to use uv, then you will have
Couldn't you say that about any know how?
>Remember to wave goodbye to all the users passing the language by.
Given the size of the python user base, this doesn't seem like a big problem.
Any old enough language will have competing libraries that you need to learn in the long run too.
Libraries, yes. Tooling around packages/building/managing runtimes? I'm not convinced. Perl has been using CPAN like two decades now, and I wouldn't consider that ecosystem to exactly be an example of "there's only one way to do it". I feel like you're extrapolating in the wrong direction; older languages are less likely to have first party tooling for this, so they're more likely to have multiple ways of doing it, but I don't think there's much evidence that a language that started out with first party tooling will always follow that same trend. I don't think the issue with Python is it's age as much as the tooling it has was just really not good for a long time. People will probably want to replace subpar tooling regardless of the official status if there's a better alternative, but I'd expect that I'm the presence of good enough first-party tooling, people will eventually stop bothering.
I do actually think Go is a bit of an illustrative example here because it started out with just `go get` and liberal use of vendoring, then accumulated a variety of attempted replacements (e.g. godep and dep, which confusingly were not the same thing), but eventually the first party tooling around modules became a thing and after some time it seems like pretty much everyone dropped those interim tools and standardized on the official tooling. I feel like this actually shows that the proliferation of tooling can actually be stopped even if it didn't exist early on, provided that there's a process for making it official.
python packaging has been made usable by uv pretty recently.
before that it was a never ending series of approaches... that has now hopefully really been solved.
(uv is ironically not written in python, but, such is life)
So does that also solve the many issues
I've never worked on a super big project, so when it comes to python dependancies the issue I always had is some C/C++ packages trying to build locally and fsiling. While this is mostly a problem on windows I've encountered it on mac as well. I assume uv doesn't have a way to solve this?
[dead]