Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uv's killer feature is making ad-hoc environments easy

valatka.dev

Post reply on HN
Print view View original

301–310 of 428 posts

Re: Uv's killer feature is making ad-hoc environments easy

#301

Post by zahlman »

RobinL wrote: post #80
stevage wrote: post #26

As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.

I've only recently started with uv, but this is one thing it seems to solve nicely. I've tried to get into the mindset of only using uv for python stuff - and hence I haven't installed python using homebrew, only uv. You basically need to just remember to never call python directly. Instead use uv run and uv pip install. That ensures you're always using the uv installed python and/or a venv. Python based tools where…

>You basically need to just remember to never call python directly. Instead use uv run and uv pip install.

I don't understand why people would rather do this part specfically, rather than activate a venv.

Re: Uv's killer feature is making ad-hoc environments easy

#302

Post by zahlman »

wruza wrote: post #197
TZubiri wrote: post #57

Earlier quoted context omitted.

Because node.js isn't a dependency of the Operating system. Also we don't have a left pad scale dependency ecosystem that makes version conflicts such a pressing issue.

Oh, tell us OS can’t venv itself a separate python root and keep itself away from what user invents to manage deps. This is non-explanation appealing to authority while it’s clearly just a mess lacking any thought. It just works like this. we don't have a left pad scale dependency ecosystem that makes version conflicts such a pressing issue TensorFlow.

>Oh, tell us OS can’t venv itself a separate python root and keep itself away from what user invents to manage deps.

I've had this thought too. But it's not without its downsides. Users would have to know about and activate that venv in order to, say, play with system-provided GTK bindings. And it doesn't solve the problem that the user may manage dependencies for more than one project, that don't play nice with each other. If everything has its own venv, then what is the "real" environment even for?

Re: Uv's killer feature is making ad-hoc environments easy

#303

Post by krick »

mk12345 wrote: post #289
krick wrote: post #259

Ok, this must be a dumb question answered by the manual, but I still haven't got my hands on uv, so: but does it solve the opposite? I mean, I pretty much never want any "ad-hoc" environments, but I always end up with my .venv becoming an ad-hoc environment, because I install stuff while experimenting, not bothering to patch requirements.txt, pyproject.toml or anything of the sort. In fact, now I usually don't even b…

I think it does! uv add [0] adds a dependency to your pyproject.toml, as well as your environment. If you change your pyproject.toml file manually, uv sync [1] will update your environment accordingly. [0]: https://docs.astral.sh/uv/guides/projects/#managing-dependen... [1]: https://docs.astral.sh/uv/reference/cli/#uv-sync

If I read [1] correctly, it seems it checks against lockfile, not pyproject.toml. So it seems like it won't help if I change pyproject.toml manually. Which is a big inconveniece, if so.

Whatever, I think I'll try it for myself later today. It's long overdue.

Re: Uv's killer feature is making ad-hoc environments easy

#304

Post by zahlman »

meitham wrote: post #258
BeeOnRope wrote: post #42

Earlier quoted context omitted.

Note that in general calling the venv python directly vs activating the venv are not equivalent. E.g. if the thing you run invokes python itself, it will use the system python, not the venv one in the first case.

Surely if you want to invoke python you call sys.executable otherwise if your subprocess doesn’t inherit PATH nothing will work with uv or without uv

In rare cases, programs might also care about the VIRTUAL_ENV environment variable set by the activate script, and activation may also temporarily clear out any existing PYTHONHOME (a rarely used override for the location of the standard library). But yes, in general you can just run the executable directly.

Re: Uv's killer feature is making ad-hoc environments easy

#305

Post by globular-toast »

zahlman wrote: post #288
meitham wrote: post #252

Earlier quoted context omitted.

uv is great, but downloading and installing base python interpreter is not a good feature as it doesn’t fetch that from PSF but from a project on GitHub, that very same project says this is compiled for portability over performance, see https://gregoryszorc.com/docs/python-build-standalone/main/

>that very same project says this is compiled for portability over performance Realistically, the options on Linux are the uv way, the pyenv way (download and compile on demand, making sure users have compile-time dependencies installed as part of installing your tool), and letting users download and compile it themself (which is actually very easy for Python, at least on my distro). Compiling Python is not especiall…

Yes, which is why it's silly to do it. Developers (not "users"!) need to learn how to install Python on their system. I honestly don't know how someone can call themselves a Python developer if they can't even install the interpreter!

Re: Uv's killer feature is making ad-hoc environments easy

#306

Post by ErikBjare »

I really thought this would mention uv script deps (standardized by some PEP) together with a `#!/usr/bin/env -S uv run` shebang line which automatically install the deps on execution.

Has been super useful to write single-file tools/scripts which LLMs can understand and run easily.

Re: Uv's killer feature is making ad-hoc environments easy

#307

Post by lmm »

mixmastamyk wrote: post #260
athrun wrote: post #163

Earlier quoted context omitted.

> sudo apt-get install python3.10 python3.11 python3.12 This assumes the Python version you need is available from your package manager's repo. This won't work if you want a Python version either newer or older than what is available. > You are incorrect about needing to use an additional tool to install a "global" tool like `ruff`; `pip` does this by default when you're not using a virtual environment. True, but it'…

>> You are incorrect about needing to use an additional tool to install a "global" tool like `ruff`; `pip` does this by default when you're not using a virtual environment. >True, but it's not best practice to do that because while the tool gets installed globally, it is not necessarily linked to a specific python version, and so it's extremely brittle. "Globally" means installed with sudo. These are installed into t…

> It works fine until you upgrade to a new version of python, in which case you install the package again.

Or you install a second global tool that depends on an incompatible version of a library.

Re: Uv's killer feature is making ad-hoc environments easy

#308

Post by zahlman »

CGamesPlay wrote: post #217

I want to like uv, but unfortunately there's some kind of technical distinction between a Python "package manager" and a "build system". Uv doesn't include a "build system", but encourages you to use some other one. The net result is that external dependencies don't build the same as on Poetry, don't work, and uv points the finger at some other dependency. I do hope the situation changes one day. Python packaging is…

It's not "some sort of technical distinction". Package managers are for keeping track of which pieces of code you need in your project's environment. Build systems are for... building the code, so that it can actually be used in an environment.

Usually, you can directly make a pre-built wheel, and then an installer like Pip or uv can just unpack that into the environment. If it needs to be build on the user's machine, then you offer an sdist, which specifies its build backend. The installer will act as a build frontend, by downloading and setting up the specified backend and asking it to make a wheel from the sdist, then installing the wheel.

Poetry's build backend (`poetry.masonry`) doesn't build your external dependencies unless a) you obtain an sdist and b) the sdist says to use that backend. And in these cases, it doesn't matter what tools you're using. Your installer (which could be Pip, which is not a package manager in any meaningful sense) can work with `poetry.masonry` just fine.

If you can give a much more specific, simple, reproducible example of a problem you encountered with external dependencies and uv, I'll be happy to try to help.

Re: Uv's killer feature is making ad-hoc environments easy

#309

Post by zahlman »

miohtama wrote: post #38
easton wrote: post #20

Earlier quoted context omitted.

There’s a shebang now. as of PEP 722 you can declare dependencies in a comment at the top of a single file script that a package manager can choose to read and resolve. uv has support for it: https://docs.astral.sh/uv/guides/scripts/#running-a-script-w... (which only helps if your team is all in on uv, but maybe they are)

Do other package managers support this yet?

Pipx isn't in any meaningful sense a package manager (although it can manage environments to a limited extent), but the `pipx run` command supports this PEP as of version 1.4.2.

Re: Uv's killer feature is making ad-hoc environments easy

#310

Post by zahlman »

mianos wrote: post #68
faizshah wrote: post #16

I love this, the biggest problem I have right now with python scripts is distributing my single file utility scripts (random ops scripts). I wish there was a way to either shebang something like this or build a wheel that has the full venv inside.

You mean like pyinstaller https://pyinstaller.org that takes your python and makes a standalone, self extracting or onedir archive to convert you ops script plus dependencies into something you can just distribute like a binary?

This makes sense when you need to provision Python itself to the end user, not just third-party libraries.
Post reply on HN