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

381–390 of 428 posts

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

#381

Post by mixmastamyk »

lmm wrote: post #307
mixmastamyk wrote: post #260

Earlier quoted context omitted.

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

Never happened, and exceedingly unlikely to because your user-wide tools should be few.

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

#382

Post by mixmastamyk »

orra wrote: post #315
mixmastamyk wrote: post #260

Earlier quoted context omitted.

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

Nah, pip is still brittle here because it uses one package resolution context to install all your global tools. So if there is a dependency clash you are out of luck. So that's why pipx was required, or now, UV.

Not happened in the last fifteen years, never used pipx. See my other replies.

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

#383

Post by zahlman »

zahlman wrote: post #237
PaulHoule wrote: post #32

Earlier quoted context omitted.

pip's resolving algorithm is not sound. If your Python projects are really simple it seems to work but as your projects get more complex the failure rate creeps up over time. You might pip install something and have it fail and then go back to zero and restart and have it work but at some point that will fail. conda has a correct resolving algorithm but the packages are out of date and add about as many quality probl…

> You might `pip install` something and have it fail and then go back to zero and restart and have it work but at some point that will fail. Can you give a concrete example, starting from a fresh venv, that causes a failure that shouldn't happen? > but it was written in Python and thus had problems with maintaining its own stable Python enivronment All it has to do is create an environment for itself upon installatio…

It occurs to me later: `installer` isn't compiling the .py files to .pyc, which probably accounts for the time difference. This can normally be done on demand (or suppressed entirely) but Pip wants to do it up front. Bleh. "Installing" from already-unpacked files would still be much faster.

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

#384

Post by zahlman »

bennofs wrote: post #341
globular-toast wrote: post #305

Earlier quoted context omitted.

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!

I for one enjoy the convenience of automatically installing python versions. Yes I know how to do it manually. Yes it is possible to install multiple versions. But that does not mean I want to do it every time, just to test how things behave in different python versions. For that, it's also okay if it does not install the most performant version of the interpreter.

>Yes it is possible to install multiple versions. But that does not mean I want to do it every time, just to test how things behave in different python versions

You only have to do it once per version with this approach. Then you can create venvs from that base, and it's basically instantaneous if you do it `--without-pip`.

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

#385

Post by mixmastamyk »

TeMPOraL wrote: post #333
mixmastamyk wrote: post #260

Earlier quoted context omitted.

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

> "Globally" means installed with sudo. These are installed into the user folder under ~/.local/ and called a user install by pip. > It works fine until you upgrade to a new version of python, in which case you install the package again. Debian/Ubuntu doesn't want you to do either, and tell you you'll break your system if you force it (the override flag is literally named "--break-system-packages"). Hell, if you're d…

Not Debian specific. The braindead option was added by pip to scare off newbies.

No one with the most basic of sysad skills is “bricked” by having to uninstall a library. Again have not experienced a conflict in over 15 years.

Use the system package manager or buid yourself for tools like cmake.

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

#386

Post by zahlman »

orf wrote: post #377
zahlman wrote: post #373

Earlier quoted context omitted.

>So many misunderstandings here :/ I've spent most of the last two years making myself an expert on the topic of Python packaging. You can see this through the rest of the thread. >No, it doesn’t. It’s not a lockfile: it’s a snapshot of the dependencies you have installed. Yes, it does. It's a snapshot of the dependencies that you have installed. For each of those dependencies, there is some set of Python versions it…

Holy hell dude, you don’t need to write a novel for every reply. It’s not a lockfile because it’s a snapshot of what you have installed . End of. It doesn’t handle environment markers nor is it reproducible. Given any non-trivial set of dependencies and/or more than 1 platform, it will lead to confusing issues. Those confusing issues are the reason for lock files to exist, and the reason they are not just “the output…

>It’s not a lockfile because it’s a snapshot of what you have installed.

I didn't say it was. I said that it solves the problems that many people mistakenly think they need a lockfile for.

(To be clear: did you notice that I am not the person who originally said "'pip freeze' generates a lockfile."?)

>It doesn’t handle environment markers nor is it reproducible.

You can write environment markers in it (of course you won't get them from `pip freeze`) and Pip will respect them. And there are plenty of cases where no environment markers are applicable anyway.

It's perfectly reproducible insofar as you get the exact specified version of every dependency, including transitive dependencies.

>Given any non-trivial set of dependencies and/or more than 1 platform, it will lead to confusing issues.

Given more than 1 platform, with differences that actually matter (i.e. not pure-Python dependencies), you cannot use a lockfile, unless you specify to build everything from source. Because otherwise a lockfile would specify wheels as exact files with their hashes that were pre-built for one platform and will not work on the others.

Anyway, feel free to show a minimal reproducible example of the confusion you have in mind.

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

#387

Post by trallnag »

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.

How has NodeJS solved it? There are tons of version managers for Node.

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

#388

Post by orf »

zahlman wrote: post #386
orf wrote: post #377

Earlier quoted context omitted.

Holy hell dude, you don’t need to write a novel for every reply. It’s not a lockfile because it’s a snapshot of what you have installed . End of. It doesn’t handle environment markers nor is it reproducible. Given any non-trivial set of dependencies and/or more than 1 platform, it will lead to confusing issues. Those confusing issues are the reason for lock files to exist, and the reason they are not just “the output…

>It’s not a lockfile because it’s a snapshot of what you have installed. I didn't say it was. I said that it solves the problems that many people mistakenly think they need a lockfile for. (To be clear: did you notice that I am not the person who originally said "'pip freeze' generates a lockfile."?) >It doesn’t handle environment markers nor is it reproducible. You can write environment markers in it (of course you…

> Given more than 1 platform, with differences that actually matter (i.e. not pure-Python dependencies), you cannot use a lockfile, unless you specify to build everything from source. Because otherwise a lockfile would specify wheels as exact files with their hashes that were pre-built for one platform and will not work on the others.

What is more likely:

1. Using a lockfile means you cannot use wheels and have to build from source

2. You don’t know what you’re talking about

(When deciding, keep in mind that every single lockfile consuming and producing tool works fine with wheels)

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

#389

Post by dragonwriter »

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…

> Node.js's replacement for virtualenv is literally just a folder named "node_modules".

Node_modules doesn't support an isolated node interpreter distinct from what may be installed elsewhere on the machine. Third party tools are available that do that for node, but node_modules alone addresses a subset of the issues that venvs solve.

OTOH, its arguably undesirable that there isn't a convenient way in Python to do just what node_modules does without the extra stuff that venvs do, because there are a lot of use cases where that kind of solution would be sufficient and lower overhead.

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

#390

Post by dragonwriter »

zahlman wrote: post #325
imtringued wrote: post #297

Earlier quoted context omitted.

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

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

venv is a dedicated tool.

virtualenv is a different dedicated tool.

Post reply on HN