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

321–330 of 428 posts

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

#321

Post by zahlman »

botanical76 wrote: post #294
zahlman wrote: post #206

Earlier quoted context omitted.

(I will likely base a blog post in my packaging series off this comment later.) What people seem to miss about Pip is that it's by design, not a package manager. It's a package installer , only. Of course it doesn't handle the environment setup for you; it's not intended for that. And of course it doesn't keep track of what you've installed, or make lock files, or update your `pyproject.toml`, or... What it does do i…

Do you feel that Npm, mix, cargo went the wrong way, doing too much? It seems like their respective communities _love_ the standard tooling and all that it does. Or is Python fundamentally different?

Python is fundamentally used in different ways, and in particular is much more often used in conjunction with code in other languages that has to be compiled separately and specially interfaced with. It also has a longer history, and a userbase that's interested in very different ways of using Python than the "development ecosystem" model where you explicitly create a project with the aim of adding it to the same package store where you got your dependencies from. Different users have wildly different needs, and tons of the things workflow tools like uv/Poetry/PDM/Hatch/Flit do are completely irrelevant to lots of them. Tons of users don't want to "manage dependencies"; they want to have a single environment containing every package that any of their projects ever uses (and a shoulder to cry on if a version conflict ever arises from that). Tons of users don't want to make a "project" and they especially don't want to set up their Python code as a separate, reusable thing, isolated from the data they're working on with it right now. Tons of users think they know better than some silly "Pip" tool about exactly where each of their precious .py files ought to go on your hard drive. Tons of developers want their program to look and feel like a stand-alone, independent application, that puts itself in C:\Program Files and doesn't expect users to know what Python is. People more imaginative than I could probably continue this train of thought for quite a bit.

For many of the individual tasks, there are small Unix-philosophy tools that work great. Why is typing `poetry publish` better than typing `twine upload`? (And it would be just `twine`, except that there's a `register` command that PyPI doesn't need in the first place, and a `check` command that's only to make sure that other tools did their job properly - and PyPI will do server-side checks anyway.) Why is typing `poetry run ...` better than activating the venv with the script it provided itself, and then doing the `...` part normally?

An all-in-one tool works when people agree on the scope of "all", and you can therefore offer just one of them and not get complaints.

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

#322

Post by IanCal »

zahlman wrote: post #221
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'…

> pip doesn't resolve dependencies of dependencies. This is simply incorrect. In fact the reason it gets stuck on resolution sometimes is exactly because it resolved transitive dependencies and found that they were mutually incompatible. Here's an example which will also help illustrate the rest of my reply. I make a venv for Python 3.8, and set up a new project with a deliberately poorly-thought-out pyproject.toml:…

> This is simply incorrect. In fact the reason it gets stuck on resolution sometimes is exactly because it resolved transitive dependencies and found that they were mutually incompatible.

The confusion might be that this used to be a problem with pip. It looks like this changed around 2020, but before then pip would happily install broken versions. Looking it up, this change of resolution happened in a minor release.

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

#323

Post by amelius »

wizzard0 wrote: post #180
amelius wrote: post #61

Earlier quoted context omitted.

How does that work with the shebang?

#!uv run # /// script # requires-python = ">=3.10" # dependencies = [ # "click>8", # "rich", # ] # /// and that's it

Cool. I wasn't sure it would skip the first comment line.

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

#324

Post by graemep »

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…

I also tend to use the OS package manager to install other binary dependencies. Pip does the rest perfectly well.

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

#325

Post by zahlman »

imtringued wrote: post #297
zahlman wrote: post #206

Earlier quoted context omitted.

(I will likely base a blog post in my packaging series off this comment later.) What people seem to miss about Pip is that it's by design, not a package manager. It's a package installer , only. Of course it doesn't handle the environment setup for you; it's not intended for that. And of course it doesn't keep track of what you've installed, or make lock files, or update your `pyproject.toml`, or... What it does do i…

Virtualenv should have never existed in the first place. So you claiming that UV or whatever tool is doing too much, sounds to me like you're arguing based on "traditionalist" or "conservative" reasons rather than doing any technical thinking here. Node.js's replacement for virtualenv is literally just a folder named "node_modules". Meanwhile python has an entire tool with strange ideosyncracies that you have to pay…

Uv doing things I'm not interested in, has absolutely nothing to do with the design of virtualenvs. But virtualenvs are easy enough to work with; they absolutely don't "necessitate a whole dedicated tool just to manage" unless you could the `activate` script that they come with.

But also, Uv uses them anyway. Because that's the standard. And if the Python standard were to use a folder like node_modules, Uv would follow suit, and so would I. And Uv would still be doing package management and workflow tasks that I'm completely uninterested in, and presenting an "every command is prefixed with the tool suite name* UI that I don't like.

There was a proposal for Python to use a folder much like node_modules: see https://discuss.python.org/t/pep-582-python-local-packages-d... . It went through years of discussion and many problems with the idea were uncovered. One big issue is that installing a Python package can install more than just the importable code; the other stuff has to be put somewhere sensible.

>So again you're pretending that this is such a big deal that it needs a whole other tool

I make no such claim. The tool I want is not for managing virtual environments. It's for replacing Pip, and offering a modicum of convenience on top of that. Any time you install a package, no matter whether you use Pip or uv or anything else, you have to choose (even if implicitly) where it will be installed. Might as well offer the option of setting up a new location, as long as we have a system where setup is necessary.

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

#326

Post by Zizizizz »

shlomo_z wrote: post #190
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/

Is it possible for my IDE (vscode) to support this? Currently my IDE screams at me for using unknown packages and I have no type hinting, intellisense, etc.

With your python plugin you should be able choose .venv/bin/python as your interpreter after you've run `uv sync` and everything should resolve

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

#327

Post by zahlman »

orf wrote: post #319
zahlman wrote: post #273

Earlier quoted context omitted.

A list of currently installed packages in the current environment , with their exact versions. This is only the actually needed packages, with their transitive dependencies, unless you've left something behind from earlier in development. If you're keeping abstract dependencies up to date in `pyproject.toml` (which you need to do anyway to build and release the project ), you can straightforwardly re-create the envir…

Doesn’t account for differences in platforms or Python versions, and doesn’t contain resolved dependency hashes. So it’s a “lockfile” in the strictest, most useless definition: only works on the exact same Python version, on my machine, assuming no dependencies have published new packages.

Look, I'm not trying to sell this as a full solution - I'm just trying to establish that a lot of people really don't need a full solution.

>only works on the exact same Python version

It works on any Python version that all of the dependencies work on. But also it can be worked around with environment markers, if you really can support multiple Python versions but need a different set of dependencies for each.

In practical cases you don't need anything like a full (python-version x dependency) version matrix. For example, many projects want to use `tomllib` from the standard library in Python 3.11, but don't want to drop support for earlier Python because everything else still works fine with the same dependency packages for all currently supported Python versions. So they follow the steps in the tomli README (https://github.com/hukkin/tomli?tab=readme-ov-file#building-...).

>on my machine

(Elsewhere in the thread, people were trying to sell me on lock files for library development, to use specifically on my machine while releasing code that doesn't pin the dependencies.)

If my code works with a given version of a dependency on my machine, with the wheel pre-built for my machine, there is no good reason why my code wouldn't work on your machine with the same version of the dependency, with the analogous wheel - assuming it exists in the first place. It was built from the same codebase. (If not, you're stuck building from source, or may be completely out of luck. A lockfile can't fix that; you can't specify a build artifact that doesn't exist.)

This is also only relevant for projects that include non-Python code that requires a build step, of course.

>assuming no dependencies have published new packages.

PyPI doesn't allow you to replace the package for the same version. That's why there are packages up there with `.post0` etc. suffixes on their version numbers. But yes, there are users who require this sort of thing, which is why PEP 751 is in the works.

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

#328

Post by BiteCode_dev »

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.

Node hasn't solved this mess because it doesn't have the same mess.

It has a super limited compiled extensions ecosystem, plugin ecosystem and is not used as a system language in mac and linux.

And of course node is much more recent and the community less diverse.

tldr: node is playing in easy mode.

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

#329

Post by rochacon »

krick wrote: post #299
zahlman wrote: post #287

Earlier quoted context omitted.

>installing stuff automatically changes pyprpject.toml (or whatever the standard will be with uv) pyproject.toml represents an inter-project standard and Charlie Marsh has committed to sticking with it, along with cooperating with future Python packaging PEPs. But while you can list transitive dependencies, specify exact versions etc. in pyproject.toml, it's not specifically designed as a lockfile - i.e., pyproject.t…

> uv isn't going to do things like analyzing your codebase Sure, that's not what I meant (unless we call pyproject.toml a part of your codebase, which it kinda is, but that's probably not what you meant). In fact, as far as I can tell from your answer, Python does move in the direction I'd like it to move, but it's unclear by how far it will miss and if how uv handles it is ergonomical. As I've said, I think PHP's co…

I believe you're searching for `uv sync`: https://docs.astral.sh/uv/getting-started/features/#projects

With this, you can manage the dependency list via `uv add/remove` (or the `pyproject.toml` directly), and run `uv sync` to add/remove any dependencies to the managed virtual env.

Edit: adding about uv add/uv remove

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

#330

Post by BiteCode_dev »

andelink wrote: post #292
cyrialize wrote: post #192

For anyone that used rye, it's worth noting that the creator of rye recommends using uv. Also, rye is going to be continually updated to just interface with uv until rye can be entirely replaced by uv.

I believe they are from the same author, Charlie Marsh / Astral

no armin created rye then gave it to astral
Post reply on HN