Live data from Hacker News

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

231–240 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#231

I 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

> 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…

> Python as a general purpose utility

This ideology is what caused all the problems to begin with, the base python is built as if it's the only thing in the entire operating systems environment when it's entire packaging system is also built in a way that makes that impossible to do without manually having to juggle package conflicts/incompatibilities.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#232

I 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

the thing is I never had issues with virtual environments -- uv just allows me to easily determine what version of python that venv uses.

you mean you can't just do `venv/bin/python --version`?

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#233

I 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

> 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 your system package manager is managing, that it doesn't know how to deal with, because they didn't come from a system package.

But it's worse now because of how many system tools are written in Python — i.e., a mark of Python's success.

Notably, these tools commonly include the system package manager itself. Since you mentioned Debian (actually this is Mint, but ya know):

  $ file `which apt`
  /usr/local/bin/apt: Python script, ASCII text executable
> Now you get endlessly chastised for trying to use Python as a general purpose utility.

No, you don't. Nothing prevents you from running scripts with the system Python that make use of system-provided libraries (including ones that you install later with the system package manager).

If you need something that isn't packaged by your distro, then of course you shouldn't expect your distro to be able to help with it, and of course you should expect to use an environment isolated from the distro's environment. In Python, virtual environments are the method of isolation. All reasonable tooling uses them, including uv.

> Debian was a bastion of sanity with the split between dist_packages and site_packages but that's ruined now too.

It's not "ruined". If you choose to install the system package for pip and to use it with --break-system-packages, the consequences are on you, but you get the legacy behaviour back. And the system packages still put files separately in dist-packages. It's just that... doing this doesn't actually solve all the problems, fundamentally because of how the Python import system works.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#234

For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script: #!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.11" # dependencies = [ "modules", "here" ] # /// The script now works like a standalone executable, and uv will magically install and use the specified modules.

As long as your `/usr/bin/env` supports `-S`, yes. It will install and use distribution packages , to use PyPA's terminology; the term "module" generally refers to a component of an import package . Which is to say: the names you write here must be the names that you would use in a `uv pip install` command, not the names you `import` in the code, although they may align. This is an ecosystem standard ( https://peps.p…

> As long as your

linux core utils have supported this since 2018 (coreutils 8.3), amusingly it is the same release that added `cp --reflink`. AFAIK I know you have to opt out by having `POSIX_CORRECT=1` or `POSIX_ME_HARDER=1` or `--pedantic` set in your environment. [1]

freebsd core utils have supported this since 2008

MacOS has basically always supported this.

---

1. Amusingly despite `POSIX_ME_HARDER` not being official a alrge swapt of core utils support it. https://www.gnu.org/prep/standards/html_node/Non_002dGNU-Sta...

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#235
post #173
post #115

Earlier quoted context omitted.

This isn't a comment just about Python.. but it should just work. There shouldn't be constant ceremony for getting and keeping environments running.

There are basically 0 other programming languages that use the "directory/shell integration activated virtual environment", outside of Python. How does the rest of the world manage to survive without venvs? Config files in the directory. Shocking, really :-)))

what happens when you have two projects using different versions of node, etc? isn't that a massive headache?

not that it's great to start with, but it does happen, no?

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#236

Yes, uv is probably the best thing to happen to the Py ecosystem in the last decade. That is mainly because the rest of the ecosystem is somewhere between garbage fire and mediocre at best. uv in itself is a great tool, I have no complaints about it whatsoever! But we have to remember just how bad the rest of things are and never forget that everything's still in a pretty bad state even after more than 3 ** DECADES *…

Got a specific example in mind for garbage fire and mediocre?

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#237
post #145

I still feel bitten by diving into poetry when starting some projects. Has the ecosystem fully moved on to uv, now? Do they have good influence on what python's main ecosystem is moving to?

> Has the ecosystem fully moved on to uv, now?

It's moving pretty quick.

> Do they have good influence on what python's main ecosystem is moving to?

Yes, they're an early adaptor/implementer of the recent pyproject.toml standards.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#238
post #232

Earlier quoted context omitted.

the thing is I never had issues with virtual environments -- uv just allows me to easily determine what version of python that venv uses.

you mean you can't just do `venv/bin/python --version`?

he means "choose", not "check"

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#239

I 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.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#240
post #173
post #115

Earlier quoted context omitted.

This isn't a comment just about Python.. but it should just work. There shouldn't be constant ceremony for getting and keeping environments running.

There are basically 0 other programming languages that use the "directory/shell integration activated virtual environment", outside of Python. How does the rest of the world manage to survive without venvs? Config files in the directory. Shocking, really :-)))

The only word in the `source .venv/bin/activate` command that isn't a complete red flag that this was the wrong approach is probably bin. Everything else is so obviously wrong.

source - why are we using an OS level command to activate a programming language's environment

.venv - why is this hidden anyway, doesn't that just make it more confusing for people coming to the language

activate - why is this the most generic name possible as if no other element in a system might need to be called the activate command over something as far down the chain as a python environment

Feels dirty every time I've had to type it out and find it particularly annoying when Python is pushed so much as a good first language and I see people paid at a senior level not understand this command.

Post reply on HN