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

311–320 of 428 posts

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

#311

Post by zahlman »

PaulHoule wrote: post #77
curiousgal wrote: post #56

Earlier quoted context omitted.

Well, when you're building python packages that have non python dependencies and a big chunk of your users are on Windows, conda is the only option, even in 2025 :) Examples include, quant libraries, in-house APIs/tools, etc.

Circa 2018, I figured out how to pack up the CUDA libraries inside conda for Windows so I could have different conda environments with different versions of CUDA which was essential back then because if you had a model that was written w/ a certain version of Tensorflow you had to have a matching CUDA and if you used NVIDIA's we-need-your-email-address installers you could only have one version of CUDA installed at a…

For that matter, you can install arbitrary content from a wheel with Pip.

The problem is all the things that do need to be installed in a particular place. Linux seems to have a lot of those, especially if they're build-time dependencies for something else. Hence the need for, and slow development of, https://peps.python.org/pep-0725/ (relevant background, though I'm sure you know this sort of stuff: https://pypackaging-native.github.io/ ).

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

#312

Post by astronautas »

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…

Hey, I actually made a silly mistake in my post, indeed you first activate the environment and then install stuff in it. Fixed!

I disagree though it is activated immediately, or at least to me with venv I always have to activate it explicitly.

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

#313

Post by baq »

zahlman wrote: post #248
jshen wrote: post #240

Earlier quoted context omitted.

> Well, sure; Pip can't respect a version pin that doesn't exist anywhere in your project. If the specific version of Pandas you want says that it's okay with a range of Numpy versions, then of course Pip has freedom to choose one of those versions. If that matters, you explicitly specify it Nearly every other language solves this better than this. What your suggesting breaks down on large projects.

>Nearly every other language solves this better than this. "Nearly every other language" determines the exact version of a library to use for you, when multiple versions would work, without you providing any input with which to make the decision? If you mean "I have had a more pleasant UX with the equivalent tasks in several other programming languages", that's justifiable and common, but not at all the same. >What y…

IMHO the clear separation between lockfile and deps in other package managers was a direct consequence of people being confused about what requirements.txt should be. It can be both and could be for ages (pip freeze) but the defaults were not conductive to clear separation. If we started with lockfile.txt and dependencies.txt, the world may have looked different. Alas.

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

#314

Post by baq »

macNchz wrote: post #204
PaulHoule wrote: post #107

Earlier quoted context omitted.

My experience was that docker was a tool data scientists would use to speedrun the process of finding broken Pythons. For instance we'd inexplicably find a Python had Hungarian as the default charset, etc. The formula was - Docker - Discipline = Chaos Docker - Discipline = Chaos Docker + Discipline = Order but - Docker + Discipline = Order If you can write a Dockerfile to install something you can write a bash script…

> If you can write a Dockerfile to install something you can write a bash script. Docker is great for making sure that magic bash script that brings the system up actually works again on someone else’s computer or after a big upgrade on your dev machine or whatever. So many custom build scripts I’ve run into over the years have some kind of unstated dependency on the initial system they were written on, or explicit d…

Unspoken libc dependencies are my favorite. Granted, you need to wait a few years after launching the project to feel that pain, but once you’re there, the experience is… unforgettable.

Second best are OpenSSL dependencies. I sincerely hope I won’t have to deal with that again.

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

#315

Post by orra »

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…

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.

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

#316

Post by zahlman »

secondcoming wrote: post #84

[flagged]

>you need a virtual environment for some reason

You have always needed on, practically speaking. Python isn't designed to have multiple versions of the same library in the same runtime environment. A virtual environment is just a separate place to put the packages you need for the current project, so that they're isolated from other packages, and thus you don't get version conflicts. This includes the system packages. If you want to play with, say, the latest version of Requests, and you try sudo installing that in a system environment, and it happens that the latest version of Requests breaks Apt (which is written in Python), you're in for a bad time.

The new warning is because even user-level installations can mess with system scripts, when those scripts are run without sudo. Also, Apt has no real way to know about or understand anything you do with Pip, so that interferes with Apt's actual package management.

>installing packages [with] sudo doesn't make them available to other users

If you use sudo to install packages for the system Python, then yes they absolutely are available to all users. But you don't see them in virtual environments by default (you can change this) because the default is to ignore the system installation's `site-packages` completely (including user-level installations).

> on ubuntu it seems pip has been replaced with 'python-*' debian packages

None of this is new, and it doesn't even remotely "replace" Pip. You're just facing a little more pressure to actually use the system package manager when installing packages for your system, since that can actually manage packages, and integrate them with the rest of your system (the non-Python parts). The Debian packages are specifically vetted and tested for this purpose and may include Canonical's own patches that you won't get from PyPI. On the other hand, PyPI provides vastly more different packages.

When you install in a virtual environment, you'll generally use Pip to do it (unless you use uv etc.). Because the environment is specifically created to be isolated from your system, so that Apt doesn't have to care.

Please see https://stackoverflow.com/questions/75608323 for details. It wasn't a snap decision; see https://discuss.python.org/t/pep-668-marking-python-base-env... for context. Arch implements analogous protections, too, for the same reasons (https://www.youtube.com/watch?v=35PQrzG0rG4). I recall Fedora having similar plans but I didn't hear about it being implemented yet.

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

#317

Post by zahlman »

globular-toast wrote: post #305
zahlman wrote: post #288

Earlier quoted context omitted.

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

The Python community has the attitude that everyone needs to be welcomed; I mostly agree, and I don't see the point in fussing about what people want to call themselves. Everyone starts somewhere, and people try really hard to help (one random example from 2022: https://discuss.python.org/t/python-appears-in-cmd/15858)

But overall, computer literacy is really on the decline these days. Nowadays before you can teach programming in any traditional sense, you may have to teach the concept of a file system, then a command line...

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

#318

Post by zahlman »

imtringued wrote: post #295
zahlman wrote: post #278

Earlier quoted context omitted.

As another library developer, of course I want to test against multiple versions. Or more accurately, I don't want to prevent my users from using different versions prematurely. My default expectation is that my code will work with a wide range of those versions, and if it doesn't I'll know - because I like to pay attention to other libraries' deprecations, just as I'd hope for my users to pay attention to mine. Lock…

>If I had a working environment and didn't want to risk breaking it right at the moment, I could just not upgrade it. The point of a lockfile is to only upgrade when you want to upgrade. I hope you understand that.

Why do I need a special file in order to not do something?

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

#319

Post by orf »

zahlman wrote: post #273
orf wrote: post #164

Earlier quoted context omitted.

No, that generates a list of currently installed packages . That’s very much not a lock file, even if it is possible to abuse it as such.

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.

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

#320

Post by wink »

wruza wrote: post #202
zo1 wrote: post #87

Earlier quoted context omitted.

Half the time something breaks in a javascript repo or project, every single damn javascript expert in the team/company tells me to troubleshoot using the below sequence, as if throwing spaghetti on a wall with no idea what's wrong. Run npm install Delete node_modules and wait 30minutes because it takes forever to delete 500MB worth of 2 million files. Do an npm install again (or yarn install or that third one that p…

So you’re not experiencing exactly this with pip/etc? I hit this “just rebuild this 10GB venv” scenario like twice a day while learning ML. Maybe it’s just ML, but then regular node projects don’t have complex build-step / version-clash deps either.

I've not used python professionally for years - but I have had to do this maybe once in many years of usage. Seen it like once more in my team(s). A rounding error.

I've seen someone having to do this in node like once every month, no matter which year, no matter which project or company.

Post reply on HN