Am I the only one who thought poetry was still the greatest available whizbang?
Uv is the best thing to happen to the Python ecosystem in a decade
261–270 of 1001 posts
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#262Earlier quoted context omitted.
As far as impact on the ecosystem I’d say uv is up there. For the language itself you are right. Curious if you’ve come across any real use cases for Gil-less python. I haven’t yet. Seems like everything that would benefit from it is already written in highly optimized native modules.
> Seems like everything that would benefit from it is already written in highly optimized native modules Or by asyncio.
asyncio is unrelated to the parallelism prevented by the GIL.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#263I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing
I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.
Good luck if you need cross-platform `requirements.txt` files.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#264Earlier quoted context omitted.
> you should just use virtualenv with pip This is the most insulting take in the ongoing ruination of Python. You used to be able to avoid virtualenvs and install scripts and dependencies directly runnable from any shell. Now you get endlessly chastised for trying to use Python as a general purpose utility. Debian was a bastion of sanity with the split between dist_packages and site_packages but that's ruined now too…
> You used to be able to avoid virtualenvs and install scripts and dependencies directly runnable from any shell. This wasn't really the case; in principle anything you installed in the system Python environment, even "at user level", had the potential to pollute that environment and thus interfere with system tools written in Python. And if you did install it at system level, that became files within the environment…
Nowadays pip also defaults to installing to the users home folder if you don't run it as root.
Basically the only thing missing from pip install being a smooth experience is something like npx to cleanly run modules/binary files that were installed to that directory. It's still futzing with the PATH variable to run those scripts correctly.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#265God yes. I got dragged into the uv when I started using copyparty and I am a fanatical admirer ever since. I also use pipx to install tools often. I really don't understand why you can't just pip install something globally. I want this package to be available to me EVERYWHERE, why can't I do it? I only use python recreationally because everyone uses python everywhere and you can't escape it. So there is a massive pos…
> I really don't understand why you can't just pip install something globally. I want this package to be available to me EVERYWHERE, why can't I do it? I only use python recreationally because everyone uses python everywhere and you can't escape it. So there is a massive possibility I am simply wrong and pip-installing something globally is a huge risk. I'm just not understanding it.
You may have a library that's been globally installed, and you have multiple projects that rely on it. One day you may need to upgrade the library for use in one project, but there are backward incompatibile changes in the upgrade, so now all of your other projects break when you upgrade the global library.
In general, when projects are used by multiple people across multiple computers, it's best to have the specific dependencies and versions specified in the project itself so that everyone using that project is using the exact same version of each dependency.
For recreational projects it's not as big of a deal. It's just harder to do a recreation of your environment.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#266Honestly though it's a pretty rough indictment of Python that the best thing to happen in a decade is that people started writing Python tools in Rust. Not even a little Rust, uv is 98% Rust. I mean, they just released 3.14 and that was supposed to be a pretty big deal.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#267This article appears to be NOT about someone who discovered uv after using venv/pip, but rather an article about someone who discovered uv after not using virtual environments at all, and is mostly excited about the cleanliness of virtual environments.
The article shows some advantages compared to plain virtual environments: In principle, you can ‘activate’ this new virtual environment like any typical virtual environment that you may have seen in other tools, but the most ‘uv-onic’ way to use uv is simply to prepend any command with uv run. This command automatically picks up the correct virtual environment for you and runs your command with it. For instance, to r…
[deleted]
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#268> Instead of > > source .venv/bin/activate > python myscript.py > > you can just do > > > uv run myscript > This is by far the biggest turn off for me. The whole point of an environment manager is set the environment so that the commands I run work. They need to run natively how they are supposed to when the environment is set, not put through a translation layer. Side rant: yes I get triggered whenever someone tells…
> They need to run natively how they are supposed to when the environment is set, not put through a translation layer.
There is a new standard mechanism for specifying the same things you would specify when setting up a venv with a python version and dependencies in the header of a single file script, so that tooling can setup up the environment and run the script using only the script file itself as a spec.
uv (and PyPA’s own pipx) support this standard.
> yes I get triggered whenever someone tells me "you can just" do this thing that is actually longer and worse than the original.
"uv run myscript" is neither longer nor worse than separately manually building a venv, activating it, installing dependencies into it, and then running the script.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#269Mojo?
Mojo stopped saying out loud they are trying to be a Python superset. Maybe they can do it one day but they're keeping that on the DL now because it's a really big ask.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#270> Instead of > > source .venv/bin/activate > python myscript.py > > you can just do > > > uv run myscript > This is by far the biggest turn off for me. The whole point of an environment manager is set the environment so that the commands I run work. They need to run natively how they are supposed to when the environment is set, not put through a translation layer. Side rant: yes I get triggered whenever someone tells…
From what I can tell (just started using uv) it doesn't break the original workflow with the venv, just adds the uv run option as well.