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

961–970 of 1001 posts

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

#961

Post by dragonwriter »

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.

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

#962

Post by monerozcash »

TZubiri wrote: post #923
monerozcash wrote: post #887

Earlier quoted context omitted.

Nobody actually inspects binaries anyway, what's the difference?

Why bother with python and open source then? Presumably every package you install with pip/uv would be source available and you could build them. The idea behind most package managers including apt and pip is that they help you build the software and try to make it easier for you without actually downloading and trusting binaries.

>Why bother with python and open source then?

Because you can easily make changes to the software, not because it's way less likely to be backdoored.

>The idea behind most package managers including apt and pip is that they help you build the software and try to make it easier for you without actually downloading and trusting binaries.

I'm so deeply confused

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

#963

Post by zahlman »

x187463 wrote: post #834
blueflow wrote: post #830

Earlier quoted context omitted.

Thats the same thing?

I think the point is you don't have to memorize the boilerplate.

This isn't really boilerplate; it declares dependencies needed in the environment, which cannot in general be inferred from static analysis of the code.

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

#964

Post by zahlman »

mr_mitm wrote: post #363
XorNot wrote: post #222

Earlier quoted context omitted.

I use this but I hate it. I want to be able to ship a bundle which needs zero network access to run, but will run. It is still frustratingly difficult to make portable Python programs.

Zipapp comes close: https://docs.python.org/3/library/zipapp.html

I'm planning to distribute PAPER as a zipapp where the bootstrap script does some initial unpacking to put wheels in a temporary directory, then delegates to the contained code (similar to how the standard library `ensurepip` works). The code that creates the zipapp is in the repository and I'm thinking of genericizing that and making it separately available, too.

Although several variations on this theme already exist, I'm sure. https://github.com/pex-tool/pex/ is arguably one of them, but it's quite a bit bulkier than what I'm looking for.

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

#965

Post by zahlman »

kristjansson wrote: post #936
Uehreka wrote: post #677

Earlier quoted context omitted.

This was always my issue with pip and venv: I don’t want a thing that hijacks my terminal and PATH, flips my world upside down and makes writing automated headless scripts and systemd services a huge pain. When I drop into a Node.js project, usually some things have changed, but I always know that if I need to, I can find all of my dependencies in my node_modules folder, and I can package up that folder and move it w…

> I don’t want a thing that hijacks my terminal and PATH The shame is ... it never had to be that way. A venv is just a directory with a pyvenv.cfg, symlinks to an interpreter in bin, and a site-packages directory in lib. Running anything with venv/bin/python _is_ running in the virtual environment. Pip operations in the venv are just venv/bin/python -m pip ... . All the source/deactivate/shell nonsense obfuscating t…

> The shame is ... it never had to be that way.

It isn't that way. Nothing is preventing you from running the venv's python executable directly.

But the original designer of the concept appears to have thought that activation was a useful abstraction. Setting environment variables certainly does a lot to create the feeling of being "in" the virtual environment.

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

#966

Post by zahlman »

Uehreka wrote: post #677
BrenBarn wrote: post #659

The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see…

This was always my issue with pip and venv: I don’t want a thing that hijacks my terminal and PATH, flips my world upside down and makes writing automated headless scripts and systemd services a huge pain. When I drop into a Node.js project, usually some things have changed, but I always know that if I need to, I can find all of my dependencies in my node_modules folder, and I can package up that folder and move it w…

> I don’t want a thing that hijacks my terminal and PATH, flips my world upside down and makes writing automated headless scripts and systemd services a huge pain.

pip and venv are not such things. The activation script is completely unnecessary, and provided as a convenience for those to whom that workflow makes more sense.

> Every time I need to containerize or setup a Python project for some arbitrary task, there’s always an issue with “Your Linux distro doesn’t support that version of Python anymore“

I can't fathom why. First off, surely your container image can just pin an older version of the distro? Second, right now I have Python versions 3.3 through 3.14 inclusive built from source on a very not-special consumer Linux distro, and 2.7 as well.

> and triggering an avalanche of new “you really shouldn’t install packages globally” messages, demanding new —yes-destroy-my-computer-dangerously-and-step-on-my-face-daddy flags and crashing my automated scripts from last year.

Literally all you need to do is make one virtual environment and install everything there, which again can use direct paths to pip and python without sourcing anything or worrying about environment variables. Oh, and fix your automated scripts so that they'll do the right thing next time.

> I know that if I was a full-time Python dev there’s a “better way” that I’d know about.

Or, when you get the "you really shouldn't install packages globally" message, you could read it — as it gives you detailed instructions about what to do, including pointing you at the documentation (https://peps.python.org/pep-0668/) for the policy change. Or do a minimum of research. You found out that venvs were a thing; search queries like "python venv best practices" or "python why do I need a venv" or "python pep 668 motivation" or "python why activate virtual environment" give lots of useful information.

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

#967

Post by zahlman »

matsemann wrote: post #722
BrenBarn wrote: post #659

The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see…

What you describe I think is what most other people hate the most about python. The fact that everything pollutes the global environment, which then becomes a mess of things depending on various versions, which also ends up breaking tools included in the OS and suddenly your whole system is effed.

> The fact that everything pollutes the global environment

This is not anything like a fact. For three years now (since the 3.11 release) Python distributions on Linux have in fact taken special measures to prevent the user from using tools other than the system package manager to install into the global environment. And for thirteen years (since the 3.3 release) Python has offered standard library functionality to create isolated environments specifically to avoid that problem. (And that functionality is based on a third party library with public releases going back eighteen years.)

Pip is designed around giving you the freedom to choose where those environments are (by separately creating them) and your strategy for maintaining them (from a separate environment per-project as a dev, to a single-environment-still-isolated-from-the-system for everything as a data scientist, and everything in between).

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

#968

Post by zahlman »

dochne wrote: post #751
matsemann wrote: post #722

Earlier quoted context omitted.

What you describe I think is what most other people hate the most about python. The fact that everything pollutes the global environment, which then becomes a mess of things depending on various versions, which also ends up breaking tools included in the OS and suddenly your whole system is effed.

I've never quite forgiven python for the time I tried to update it using yum, it failed which is then broke yum - not a fun place to end up. Treating python as a project level dependency rather than a system level dependency is just an excellent design choice.

> Treating python as a project level dependency rather than a system level dependency

Nobody is treating Python as a project level dependency. Your Linux distro treats it as a system level dependency, which is exactly why you encountered the problem you did.

When you create a virtual environment, that does not install a Python version. It just makes symlinks to a base Python.

Building Python from source, and setting it up in a way that doesn't interfere with the package manager's space and will cause no problems, is easy on major distros. I have access to over a dozen builds right now, on Mint which is not exactly a "power user" distro (I didn't want to think about it too much when I initially switched from Windows).

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

#969

Post by zahlman »

cylemons wrote: post #800
matsemann wrote: post #722

Earlier quoted context omitted.

What you describe I think is what most other people hate the most about python. The fact that everything pollutes the global environment, which then becomes a mess of things depending on various versions, which also ends up breaking tools included in the OS and suddenly your whole system is effed.

System package management is a mess in the first place, if you have a program that uses python then all the packages that it uses need to be installed globally, so you have python packages bundled as system packages which can conflict with that same package installed with pip.

> if you have a program that uses python then all the packages that it uses need to be installed globally

Only if that "program that uses Python" is itself provided by a system package for global installation.

> so you have python packages bundled as system packages which can conflict with that same package installed with pip.

Right; you can choose whether to use system packages entirely within the system-package ecosystem (and treat "it's written in Python" as an irrelevant implementation detail); or you can create an isolated environment so as to use Python's native ecosystem, native packaging, and native tools.

I don't know why anyone would expect to mingle the two without problems. Do you do that for other languages? When I tried out Ruby, its "Bundler" and "gem" system was similarly isolated from the system environment.

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

#970

Post by zahlman »

quietbritishjim wrote: post #871
BrenBarn wrote: post #659

The sticking point for me is the way tools like uv and poetry build everything around the idea of a "project". I don't want a separate environment for every project, and I don't want to start by creating a project. I want to start with an environment that has stuff in it, and I start fiddling around, and gradually something comes together that eventually will be pulled out into a separate project. From what I can see…

I have the same feeling, so I just looked it up and actually uv does support exactly that mode. It works the same as venv and pip but you just prefix a bunch of commands with "uv". Create a new virtual environment fooenv: uv venv fooenv Activate virtual environment on Windows (yes I'm sorry that's what I'm currently typing on!): .\fooenv\Scripts\activate Run some environment commands: uv pip install numpy uv pip free…

> Admittedly, there doesn't seem to be much benefit compared to traditional venv/pip for this use case.

Performance?

Post reply on HN