Hacker News new | past | comments | ask | show | jobs | submit
uv solved it, it will be the only tool people use in 2 more years. if you’re a python shop / expert then you can do pip etc but uv turned incidental python + deps from a huge PITA for the rest of us, to It Just Works simplicity on the same level or better than Golang.
Then can they please figure out some way of invoking it that doesnt require prefixing everything with 'uv'
For any command, you can create an 'alias' in your shell config. That way you can get rid of the prefix.
You can source the virtualenv like normal.
alias in ~/.zshrc?
uv run bash/zsh/your shell of choice
I don't want software on my computer, that just downloads and installs random stuff. This is the job of the OS in particular the package manager.
You're welcome to live in the 90s dark ages, I feel this attitude and the shape of the old linux distros like Debian that laboriously re-package years-old software have been one of the biggest failures of open source and squandered untold hours of human effort. It's a model that works okay for generic infrastructure but requires far too much labor and moves far too slowly with quite a poor experience for end users and developers. Why else would all modern software development (going back to perl's cpan package manager in 1995) route around it?
Do you not use non-OS package managers?

If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool?

loading story #47441840
loading story #47444020
In general I agree with you. But not for software dev packages.

The package manager I use, apt on Debian, does not package many Python development repos. They've got the big ones, e.g. requests, but not e.g. uuid6. And I wouldn't want it to - I like the limited Debian dev effort to be put towards the user experience and let the Python dev devs worry about packaging Python dev dependencies.

Don't worry, gramps, pip won't trigger your tinfoil hat.
What’s the point of constraining oneself to what is in the OS package manager? I like to keep my dependencies up to date. The versions in the OS package manager are much older.

And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.

> What’s the point of constraining oneself to what is in the OS package manager? I like to keep my dependencies up to date. The versions in the OS package manager are much older.

I favor stability and the stripping of unwanted features (e.g. telemetry) by my OS vendor over cutting edge software. If I really need that I install it into /usr/local, that it what this is for after all.

> And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.

This is a reason to select the OS. Software shouldn't require exact versions, but should stick to stable interfaces.

Then don't use it?