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

251–260 of 428 posts

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

#251

Post by [deleted] »

driggs wrote: post #157
NeutralCrane wrote: post #43

Earlier quoted context omitted.

Couple of things. - pip doesn't handle your Python executable, just your Python dependencies. So if you want/need to swap between Python versions (3.11 to 3.12 for example), it doesn't give you anything. Generally people use an additional tool such as pyenv to manage this. Tools like uv and Poetry do this as well as handling dependencies - pip doesn't resolve dependencies of dependencies. pip will only respect versio…

Yes, generally people already use an additional tool for managing their Python executables, like their operating system's package manager: $> sudo apt-get install python3.10 python3.11 python3.12 And then it's simple to create and use version-specific virtual environments: $> python3.11 -m venv .venv3.11 $> source .venv3.11/bin/activate $> pip install -r requirements.txt You are incorrect about needing to use an addi…

[deleted]

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

#252

Post by meitham »

bityard wrote: post #200

I usually stay away far FAR from shiny new tools but I've been experimenting with uv and I really like it. I'm a bit bummed that it's not written in Python but other than that, it does what it says on the tin. I never liked pyenv because I really don't see the point/benefit building every new version of Python you want to use. There's a reason I don't run Gentoo or Arch anymore. I'm very happy that uv grabs pre-compi…

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/

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

#254

Post by krick »

hamandcheese wrote: post #185
greatgib wrote: post #158

Ridiculous post: The author says that a normal route would be: - Take the proper route: - Create a virtual environment - pip install pandas - Activate the virtual environment - Run python Basically, out of the box, when you create an virtual it is immediately activated. And you would obviously need to have it activated before doing a pip install... In addition, in my opinion this is the thing that would sucks about U…

You can still use traditional venvs with UV though, if you want.

Uh, but then you don't really need uv, right?

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

#255

Post by rtpg »

aeurielesn wrote: post #96
riwsky wrote: post #52

Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

I don't understand how things like this get approved into PEPs.

It's helpful as a way to publish minimal reproductions of bugs and issues in bug reports (compared to "please clone my repo" which has so many layers of friction involved).

I would want distributed projects to do things properly, but as a way to shorthand a lot of futzing about? It's excellent

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

#256

Post by meitham »

worik wrote: post #130
PaulHoule wrote: post #48

Earlier quoted context omitted.

Python has been cleaning up a number of really lethal problems like: (i) wrongly configured character encodings (suppose you incorporated somebody else's library that does a "print" and the input data contains some invalid characters that wind up getting printed; that "print" could crash a model trainer script that runs for three days if error handling is set wrong and you couldn't change it when the script was runni…

> Python has been cleaning up a number of really lethal problems like I wish they would stick to semantic versioning tho. I have used two projects that got stuck in incompatible changes in the 3.x Python. That is a fatal problem for Python. If a change in a minor version makes things stop working, it is very hard to recommend the system. A lot of work has gone down the drain, by this Python user, trying to work aroun…

I assume these breaking changes are in the stdlib and not in the python interpreter (the language), right?

There was previous discussions about uncoupling the stdlib (python libraries) from the release and have them being released independently, but I can’t remember why that died off

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

#257

Post by zahlman »

_ZeD_ wrote: post #249
zahlman wrote: post #247

Earlier quoted context omitted.

But any tool you use for the task would do that anyway (or set them up temporarily and throw them away). Python on Windows has a standard Windows-friendly installer, and compiling from source on Linux is the standard few calls to `./configure` and `make` that you'd have with anything else; it runs quite smoothly and you only have to do it once.

I need to tell you a secret... I'm a long-life Linux user (since mandrake!) Also, I don't have a c compiler installed.

Really? I was told Mint was supposed to be the kiddie-pool version of Linux, but it gave me GCC and a bunch of common dependencies anyway.

(By my understanding, `pyenv install` will expect to be able to run a compiler to build a downloaded Python source tarball. Uv uses prebuilt versions from https://github.com/astral-sh/python-build-standalone ; there is work being done in the Python community on a standard for packaging such builds, similarly to wheels, so that you can just use that instead of compiling it yourself. But Python comes out of an old culture where users expect to do that sort of thing.)

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

#258

Post by meitham »

BeeOnRope wrote: post #42
supakeen wrote: post #9

The activation of the virtualenv is unnecessary (one can execute pip/python directly from it), and the configuring of your local pyenv interpreter is also unnecessary, it can create a virtual environment with one directly: pyenv virtualenv python3.12 .venv .venv/bin/python -m pip install pandas .venv/bin/python Not quite one command, but a bit more streamlined; I guess.

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

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

#259

Post by krick »

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 bother typing pip install, PyCharm does it for me.

This is of course bad practice. What I would like instead is what PHP's composer does: installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv), automatically freezes the versions, and then it is on git diff to tell me what I did last night, I'll remove a couple of lines from that file, run composer install and it will remove packages not explicitly added to my config from the environment. Does this finally get easy to achieve with uv?

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

#260

Post by mixmastamyk »

athrun wrote: post #163
driggs wrote: post #157

Earlier quoted context omitted.

Yes, generally people already use an additional tool for managing their Python executables, like their operating system's package manager: $> sudo apt-get install python3.10 python3.11 python3.12 And then it's simple to create and use version-specific virtual environments: $> python3.11 -m venv .venv3.11 $> source .venv3.11/bin/activate $> pip install -r requirements.txt You are incorrect about needing to use an addi…

> 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 the user folder under ~/.local/ and called a user install by pip.

I wouldn't call it "extremely brittle" either. It works fine until you upgrade to a new version of python, in which case you install the package again. Happens once a year perhaps.

The good part of this is that unused cruft will get left behind and then you can delete old folders in ~/.local/lib/python3.? etc. I've been doing this over a decade without issue.

Post reply on HN