Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A year of uv: pros, cons, and should you migrate

bitecode.dev

Post reply on HN
Print view View original

341–350 of 401 posts

Re: A year of uv: pros, cons, and should you migrate

#341

Post by gkfasdfasdf »

_whiteCaps_ wrote: post #338
gkfasdfasdf wrote: post #297

I am a casual python user, and for that I love uv. Something I haven't quite figured out yet is integration with the pyright lsp - when I edit random projects in neovim, any imports have red squiggles. Does anyone know of a good way to resolve imports for the lsp via uv?

I start a shell with "uv run bash" and start neovim from there. I'm sure there's other ways but it's a quick fix and doesn't involve mucking around with neovim config.

That's brilliant, thanks!

EDIT - 'uv run nvim' works also

Re: A year of uv: pros, cons, and should you migrate

#342

Post by ijustlovemath »

perrygeo wrote: post #332

> You don't even need to know there is a venv, or what activation means. > All those commands update the lock file automatically and transparently.... It's all taken care of. When is the python community going to realize that simple is the opposite of easy? I don't see how hiding these aspects is desirable at all; I want to know how my programming tools work! With all due respect to the author, I don't like the assum…

I think that when you, as most HN commenters are wont to do, are trying to achieve a certain level of mastery in your craft, you're going to want to dive deep, understand the abstractions, have full control, be able to start with nothing but a UDP socket and a steady hand, but that approach misses a huge number of users of these languages. You don't want scientists to have to worry about setting up a venv, you want them to analyze their data and move on with their lives. Sure, people like you or me will be able to setup and source a venv in no time, without expending much mental energy, but we're not who this product is for. It's for the rest of the users, the 99% who aren't even aware places like this exist.

All that said, I'm pretty skeptical of using uv until their monetization strategy is clear. The current setup is making me think we're in for a Docker-like license change.

Re: A year of uv: pros, cons, and should you migrate

#343

Post by remram »

The problem I have with uv is that it is not opinionated enough, or complete enough. It still needs a backend for building the package, and you still have a choice of backends.

In other words, it is a nice frontend to hide the mess that is the Python packaging ecosystem, but the mess of an ecosystem is still there, and you still have to deal with it. You'll still have to go through hatchling's docs to figure out how to do x/y/z. You'll still have to switch from hatchling to flit/pdm/setuptools/... if you run into a limitation of hatchling. As a package author, you're never using uv, you're using uv+hatchling (or uv+something) and a big part of your pyproject.toml are not uv's configuration, it is hatchling configuration.

I'm sticking with Poetry for now, which has a more streamlined workflow. Things work together. Every Poetry project uses the same configuration syntax (there are no Poetry+X and Poetry+Y projects). Issues in Poetry can be fixed by Poetry rather than having to work with the backend.

I understand that uv is still young and I am sure this will improve. Maybe they'll even pick a specific backend and put a halt to this. But of course Poetry might catch up before then.

Re: A year of uv: pros, cons, and should you migrate

#344

Post by motorest »

inejge wrote: post #141
motorest wrote: post #129

I know good naming is hard, and there are an awful lot of project names that clash, but naming a project uv is unfortunate due to the ubiquitous nature of libuv https://libuv.org/

I don't think it's particularly problematic, uv the concurrency library and uv the Python tool cover such non-overlapping domains that opportunities for confusion are minimal. (The principle is recognized in trademark law -- some may remember Apple the record label and Apple the computer company. They eventually clashed, but I don't see either of the uv's encroaching on the other's territory.)

> I don't think it's particularly problematic, uv the concurrency library and uv the Python tool cover such non-overlapping domains that opportunities for confusion are minimal.

Google returns mixed results. You may assert it's not problematic, but this is a source of noise that projects with distinct names don't have.

Re: A year of uv: pros, cons, and should you migrate

#345

Post by vergessenmir »

droelf wrote: post #249
zoobab wrote: post #225

Earlier quoted context omitted.

I am trying to configure Pixi to use it with Artifactory proxy in a corporate environment, still could not figure it out how to configure it.

Join our discord and we can help! There are lots of users that run it with Artifactory :)

I'd probably check this out in my home lab but as a corporate user the offering of discord as a support channel makes me nervous.

Discord is predominately blocked on a corporate networks. Artifactory ( & Nexus) are very common in corporate environments. Corporate proxies are even more common. This is why I'd hesitate. These are common use cases (albeit corporate) that may not be readily available in the docs.

Re: A year of uv: pros, cons, and should you migrate

#346

Post by BiteCode_dev »

selectnull wrote: post #328
BiteCode_dev wrote: post #289

Earlier quoted context omitted.

Soon uv will invlude a task runner that will take care of that use case but I get your point.

Care to elaborate? I'm not watching uv development closely, something that has been announced?

It is common to have a task runner to abstract away commands.

doit, poethepoet, just... They are simpler than builders like make or maeven, and more convenient than aliases.

E.g: i don't run ./manage.py runserver 0.0.0.0:7777, I run "just openserver".

Poetry, cargo and npm have support for this natively, and there is an open ticker for this in uv too.

So you would not do "uv run manage.py runserver" but "uv serve".

Re: A year of uv: pros, cons, and should you migrate

#347

Post by ludwik »

zelphirkalt wrote: post #315
dagw wrote: post #243

Earlier quoted context omitted.

Why did they do that? Why not have smaller venvs for separate projects? What's a 'project'? If you count every throw away data processing script and one off exploratory Jupyter notebook, that can easily be 100 projects. Certainly before uv, having one huge venv or conda environment with 'everything' installed made it much faster and easier to get that sort of work done.

In what kind of scope are these data processing scripts? In some kind of pipeline used in production I very much would expect them to have reproducible dependencies. I can understand it for exploratory Jupyter Notebook. But only in the truly exploratory stage. Say for example you are writing a paper. Reproducibility crisis. Exploring is fine, but when it gets to actually writing the paper, one needs to make ones setu…

For the (niche) Python library that I co-develop, we use this for demo scripts that live in an example/ directory in our repo. These scripts will never be run in production, but it’s nice to allow users to try them out and get a feel for how the library works before committing to installing dependencies and setting up a virtual environment.

In other words, of course, in most long-term cases, it’s better to create a real project - this is the main uv flow for a reason. But there’s value in being able to easily specify requirements for quick one-off scripts.

Re: A year of uv: pros, cons, and should you migrate

#348

Post by Zizizizz »

something98 wrote: post #37

Can someone explain a non-project based workflow/configuration for uv? I get creating a bespoke folder, repo, and uv venv for certain long-lived projects (like creating different apps?). But most of my work, since I adopted conda 7ish years ago, involves using the same ML environment across any number of folders or even throw-away notebooks on the desktop, for instance. I’ll create the environment and sometimes add n…

Just symlink the virtualenv folder and pyproject.toml it makes to whatever other project you want it to use.

Re: A year of uv: pros, cons, and should you migrate

#349

Post by selectnull »

BiteCode_dev wrote: post #346
selectnull wrote: post #328

Earlier quoted context omitted.

Care to elaborate? I'm not watching uv development closely, something that has been announced?

It is common to have a task runner to abstract away commands. doit, poethepoet, just... They are simpler than builders like make or maeven, and more convenient than aliases. E.g: i don't run ./manage.py runserver 0.0.0.0:7777, I run "just openserver". Poetry, cargo and npm have support for this natively, and there is an open ticker for this in uv too. So you would not do "uv run manage.py runserver" but "uv serve".

Yeah, I use that with `rye` now.

But still, it's not good enough for Django as there are too many management commands and I don't want to configure them in pyproject.toml file, especially since some of them take additional arguments... There is no point in using anything but django-admin command (I do have a wrapper around it, but the point remains) and that requires activated venv.

Re: A year of uv: pros, cons, and should you migrate

#350

Post by hyperbrainer »

sieve wrote: post #245
hyperbrainer wrote: post #206

Earlier quoted context omitted.

Have you tried borg [0]? Also, why not BTRFS? [0] https://borgbackup.readthedocs.io/en/stable/index.html

Have been using ZFS for the past thirteen years and all my workflows including backup are based on it. It just works.

Sure, I was just curious, since you mentioned not wanting to use ZFS without kernel support and BTRFS does have that. Being familiar with ZFS, I guess is a decent explanation.
Post reply on HN