Hacker News Reader

Comment by zmmmmm | Hacker News Reader

    > 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 me "you can just" do this thing that is actually longer and worse than the original.

View on HN

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

The `uv run` command is an optional shortcut for avoiding needing to activate the virtual environment. I personally don't like the whole "needing to activate an environment" before I can run commands "natively", so I like `uv run`. (Actually for the last 10 years I've had my `./manage.py` auto-set up the virtual environment for me.)

The `uv add` / `uv lock` / `uv sync` commands are still useful without `uv run`.

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

> I get triggered whenever someone tells me "you can just" do this thing that is actually longer and worse than the original.

Apologies for triggering you in advance, but in case you or others find it useful, here’s how to do the equivalent env-activation commands with uv: https://news.ycombinator.com/item?id=44360892

You can still do the `source .venv/bin/activate` if you want.

There's also `uv tool install` which will install things in your PATH without infecting your system with Python.

that makes me feel much better!

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.

Yes, you still have the option of manually activating a venv, and that makes sense if the amortized cost of that is lower than several instances of typing `uv run `. Though sometimes when working in one project with its venv activated, I end up needing to run a tool from another project with a separate vent, so uv still ends up being useful.

you can just point a shotgun at your foot and pull the trigger, isn't that covenient?

Unless I'm an AI, I'm pretty sure "uv run" is the same number of characters as "python". So it's shorter. Also venvs are a translation layer already, changing path.

I typically type py<TAB>.

it's not really the number of characters so much as the cognitive load of having to do something different here vs there and anything I run successfully on the command line can't be directly lifted over into scripts etc. Along with training a team of people to do that.

Reply on news.ycombinator.com