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

Uv is the best thing to happen to the Python ecosystem in a decade

emily.space

Post reply on HN
Print view View original

981–990 of 1001 posts

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#981

Post by zahlman »

dragonwriter wrote: post #961
senderista wrote: post #462

It’s puzzling why Python became the de facto standard scripting language rather than Ruby when the tooling was so inferior.

> It’s puzzling why Python became the de facto standard scripting language rather than Ruby when the tooling was so inferior. 1. Ruby tooling wasn't superior when Python became the standard. 2. Until Rails, IIRC, Ruby had limited visibility outside of Japan, whereas Python already had deep penetration in lots of fields. 3. Ruby for quite a while, IIRC, had a pretty bad story on Windows compared to Python.

> Ruby tooling wasn't superior when Python became the standard.

For that matter, when Python became the standard, the modern conception of a "language ecosystem" scarcely existed.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#982

Post by zahlman »

panzi wrote: post #590

> uv is straightforward to install. How do I install it globally on a system? Debian doesn't let me install packages via pip outside of a venv or similar.

Get a local install, then copy, move or symlink it into e.g. /usr/local/bin with sudo. It's an all-in-one statically compiled executable. (The pip-installable wheel contains this executable plus some irrelevant window dressing.)

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#983

Post by zahlman »

zahlman wrote: post #373
rieogoigr wrote: post #275

Is there a way to install this that doesn't involve piping a random URL to my shell interpreter?

Uv is available as a wheel from PyPI, so you can in fact `pip install uv` into an appropriate environment. Since it provides a command-line binary, Pipx will also happily install it into an environment it manages for you. And so on and so forth. (You can even install uv with uv, if you want to, for whatever reason.) The wheel basically contains a compiled ~53MB (huh, it's grown in recent versions) Rust executable and…

> If you want it in your system environment, you may be out of luck

That was silly of me; since all you need is the compiled executable, you can just move it to an appropriate place (that doesn't interfere with the system package manager; so, /usr/local/bin, or /opt/bin) after user installation.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#984

Post by zahlman »

AbuAssar wrote: post #640

why uv is not included by default with the standard Python binary installers?

Because officially blessing one packaging tool (or set of packaging tools) is considered out of scope for the core Python project. Even pip is provided in a very indirect way.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#985

Post by zahlman »

forrestthewoods wrote: post #332

uv is spectacular But I’m utterly shocked that UV doesn’t support “system dependencies”. It’s not a whole conda replacement. Which is a shame because I bloody hate Conda. Dependencies like Cuda and random C++ libraries really really ought to be handled by UV. I want a true genuine one stop shop for running Python programs. UV is like 80% of the way there. But the last 20% is still painful. Ideally UV would obsolete t…

> Dependencies like Cuda and random C++ libraries really really ought to be handled by UV.

Currently, there isn't a way for the packages to specify these dependencies.

In part because of the complexity of explaining exactly what is needed (and where to look for it, if you're expecting the system to provide it outside of what Python manages itself).

See https://peps.python.org/pep-0725/ and https://pypackaging-native.github.io/ for details.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#986

Post by aragilar »

neves wrote: post #939
prpl wrote: post #495

Earlier quoted context omitted.

conda (and its derivatives that are also “conda” now), and conda-forge specifically, are the best ways to install things that will work across operating systems, architectures, and languages - without having to resort to compiling everything. Want to make sure a software stack works well on a Cray with MPI+cuda+MKL, macOS, and ARM linux, with both C++ and Python libraries? It’s possible with conda-forge.

Conda is hell for multi operationg systems projects. Its lock file is OS dependent. You can't commit it and hope it will work anywere. It is probably the easiest way to install a lot of binary dependencies, good for who doesn't have experience with sofware development and don't care with reproductbility.

But either you're not doing anything that is OS specific (and then you probably could just use pip), or the OS does make a difference, and hence you need to reflect that in the lock file.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#987

Post by jonnycomputer »

zahlman wrote: post #977
jonnycomputer wrote: post #873

I have to say that I am extremely reluctant to switch over to yet another python management system (packaging, environment, python version). Every few years someone says: this is it. Switch to poetry! Okay, I did. And, at least for some academic packages, psychopy I'm looking at you, it was a friggin disaster. so. will uv install psychopy (say version 3.2.4)?

> psychopy (say version 3.2.4)? You do understand that psychopy switched to calver immediately after that version, and that this was over five years ago? That when that package was released, the oldest currently officially supported version of Python had barely started development? And that it's packaged according to legacy standards that weren't even following the best practices for 2019 (it offers only a source dis…

Psychopy is a mess of a project. It hasn't gotten any better from my perspective, even after hiring full time developers, because most of their effort is focused on the single-gui-app and Pavolovia.

things did get better when they added wheels.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#988

Post by zahlman »

jonnycomputer wrote: post #987
zahlman wrote: post #977

Earlier quoted context omitted.

> psychopy (say version 3.2.4)? You do understand that psychopy switched to calver immediately after that version, and that this was over five years ago? That when that package was released, the oldest currently officially supported version of Python had barely started development? And that it's packaged according to legacy standards that weren't even following the best practices for 2019 (it offers only a source dis…

Psychopy is a mess of a project. It hasn't gotten any better from my perspective, even after hiring full time developers, because most of their effort is focused on the single-gui-app and Pavolovia. things did get better when they added wheels.

I'm afraid uv can't do anything about that, nor could any other packaging tool. (Except perhaps one custom-made by the developers, but just getting on board with standards and best practices would surely be easier.)

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#989

Post by Phelinofist »

zahlman wrote: post #980
Phelinofist wrote: post #845

[project] name = "my_project" version = "1.0.0" requires-python = ">=3.9, =5.0.0", "pandas>=1.0.0, looks like a POM file

This is an ecosystem-wide standard (the [project] table in pyproject.toml) and has nothing to do with uv specifically.

My comment was actually tongue in cheek that the newest Python incarnation looks like the 20+ year old thing from Java, i.e. Python finally going in the right direction.

Re: Uv is the best thing to happen to the Python ecosystem in a decade

#990

Post by ActorNightly »

saagarjha wrote: post #742
ActorNightly wrote: post #623

Earlier quoted context omitted.

> But then I remember that Python is dog slow compared to other languages with comparable ergonomics and first-class support for static typing, and...idk it's a tough sell. Post like these aptly describe why companies are downsizing in lieu of AI assistants, and they are not wrong for doing so. Yes, Python is "slow". The thing is, compute is cheap these days and development time is expensive. $1000 per month is consi…

I write Python all day for work and I run into its issues all the time, be it performance or weak typing or just lack of modern language features. If you’re just vibecoding all day and that’s ok for what you want it to do, all the more power to you, but do at least take a moment to understand that when people want things you see no value in maybe they just have different requirements than you do.

Notice how you start your reply with a personal experience? Thats the big difference between what people say, and what I say. Its not about misunderstanding. You can't find a single flaw in what I said, so your only reply is "well in my experience Python sucks".

So its a you problem, not a python problem.

Strong typing doesn't make code better. Proof = Linux system is written in C, without strong typing (unless you consider basic types strong typing), and it works. Good developers make code good. While bad developers make bad code in strongly typed languages.

Python doesn't lack modern language features. It potentially lacks things that you may like, but you aren't the authority on modern language features.

If you are writing code that needs to run fast, of courses Python is a poor choice. But its likely that only a portion of your code needs to run fast, at which point you can easily use python native code interfaces, or even easier, compile a small binary written in C, and launch that from Python.

Post reply on HN