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

341–350 of 428 posts

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

#341

Post by bennofs »

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!

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.

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

#342

Post by chupasaurus »

zahlman wrote: post #257
_ZeD_ wrote: post #249

Earlier quoted context omitted.

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

In Debian build-essential package is only recommended dependency of pip. Pyenv obviously wouldn't work without it.

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

#343

Post by TeMPOraL »

PaulHoule wrote: post #107
morkalork wrote: post #89

Earlier quoted context omitted.

Ugh, I hate writing this but that's where docker and microservices comes to the rescue. It's a pain in the butt and inefficient to run but if you don't care about the overhead (and if you do care, why are you still using Python?), it works.

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.

The trick isn't installing things, it's uninstalling them. Docker container is isolated in ways your bash script equivalent is not - particularly when first developing it, when you're bound to make an occasional mistake.

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

#344

Post by mkl »

meitham wrote: post #245
stavros wrote: post #139

Earlier quoted context omitted.

Oh wow, it actually can handle the Python executable? I didn't know that, that's great! Although it's in the article as well, it didn't click until you said it, thanks!

I would avoid using this feature! It downloads a compiled portable python binary from some random github project not from PSF. That very same github project recommends against using their binary as the compilation flags is set for portability against performance. See https://gregoryszorc.com/docs/python-build-standalone/main/

https://github.com/astral-sh/python-build-standalone is by the same people as uv, so it's hardly random. The releases there include ones with profile-guided optimisation and link time optimisation [1], which are used by default for some platforms and Python versions (and work seems underway to make them usable for all [2]). I don't see any recommendation against using their binaries or mention of optimising for portability at the cost of performance on the page you link or the pages linked from it that I've looked at.

[1] https://github.com/astral-sh/uv/blob/main/crates/uv-python/d... (search for pgo)

[2] https://github.com/astral-sh/uv/issues/8015

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

#345

Post by chupasaurus »

PaulHoule wrote: post #229
coldtea wrote: post #182

Earlier quoted context omitted.

> For instance we'd inexplicably find a Python had Hungarian as the default charset, etc. Sounds quite explicable: Docker image created by Hungarian devs perhaps?

My understanding is that UTF-8 is the world's charset and that reasonable Hungarians would use that (e.g. I sure don't use us-ascii or iso-latin-1 if I can at all help it. I mean my "better half" reads 中文 so I don't have to and having it all in UTF-8 makes it easy) The other mystery is how the data sci's found it.

IIRC there was some widely used image with many derivatives that redefined locale (the one in Docker Library used POSIX since forever).

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

#346

Post by orf »

zahlman wrote: post #327
orf wrote: post #319

Earlier quoted context omitted.

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

So many misunderstandings here :/ I can’t muster the energy to correct them past these two obvious ones

> It works on any Python version that all of the dependencies work on

No, it doesn’t. It’s not a lockfile: it’s a snapshot of the dependencies you have installed.

The dependencies you have installed depend on the Python version and your OS. The obvious case would be requiring a Linux-only dependency on… Linux, or a package only required on Python > PyPI doesn't allow you to replace the package for the same version

Yes and no. You can continue to upload new wheels (or a sdist) long after a package version is initially released.

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

#347

Post by mkl »

throwup238 wrote: post #162
misiek08 wrote: post #138

Earlier quoted context omitted.

And people were laughing at PHP comments configuring framework, right?

Python was always the late born twin brother of PHP with better hair and teeth, but the same eyes that peered straight into the depths of the abyss.

Python was first released in 1991, and PHP was first released in 1995.

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

#348

Post by agoose77 »

forgingahead wrote: post #203

Python package management has always seemed like crazyland to me. I've settled on Anaconda as I've experimented with all the ML packages over the years, so I'd be interested to learn why uv, and also what/when are good times to use venv/pip/conda/uv/poetry/whatever else has come up. NeutralCrane has a really helpful comment below[0], would love to have a more thorough post on everything! [0] https://news.ycombinator.…

If you use conda, and can use conda for what you need to do, use conda w/ conda-forge. It has a much better story for libraries with binary dependencies, whereas PyPI (which `uv` uses) is basically full of static libraries that someone else compiled and promises to work.

Note, I use PyPI for most of my day-to-day work, so I say this with love!

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

#349

Post by agoose77 »

woodson wrote: post #140
jph00 wrote: post #79

Earlier quoted context omitted.

uv can’t replace conda, any more than it can replace apt or nix. Conda packages general binary packages, not just python packages. uv is just python packages.

Python packages (distributed via the Python package index, PyPI) can also be general binary packages. Try pip install cmake, for example.

Yes, but there are restrictions; for one thing, it's not trivial to share binary dependencies between Python packages; conda just handles that.

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

#350

Post by crispyambulance »

wiseowise wrote: post #284
crispyambulance wrote: post #114

I do like uv and hope to try it soon but I don't get the point of the article. Pyenv + poetry already gives you ability to "pull in local dependencies". Yes, you have to create a virtual environment and it's not "ad-hoc". But if you're going to pull in a bunch of libraries, WHY would you want to invoke python and all your work dependencies on a one liner? Isn't it much better and easier to just spell-out the dependen…

Yes! I love verbosity. It gives me job security. I’m tired of these tools making my job easier. Previously I could allocate a whole week to setup initial scaffold for the project. Also more tools - more failure points, so I can flex on stupid juniors how smart I am. Now I can’t even go to pee with how fast and easy this freaking uv is. WTF.

Well I guess I am not smart enough to dump multiple dependencies + python, densely, on one line to spin everything up so I can do “ad-hoc” computing without just spelling them out in a file. Sorry, but that just isn’t a killer feature for me and it doesn’t seem like a big deal anyway.

I do like the idea of getting rid of pyenv though. And since poetry has failed to become as widespread as I hoped, maybe uv has a better shot?

Post reply on HN