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

181–190 of 428 posts

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

#181

Post by coldtea »

morkalork wrote: post #89
PaulHoule wrote: post #32

Earlier quoted context omitted.

pip's resolving algorithm is not sound. If your Python projects are really simple it seems to work but as your projects get more complex the failure rate creeps up over time. You might pip install something and have it fail and then go back to zero and restart and have it work but at some point that will fail. conda has a correct resolving algorithm but the packages are out of date and add about as many quality probl…

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.

>and if you do care, why are you still using Python?

Because I get other advantages of it. Giving in to overhead on one layer, doesn't mean I'm willing to give it up everywhere.

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

#182

Post by coldtea »

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…

>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?

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

#183

Post by nightpool »

coldtea wrote: post #178
athrun wrote: post #163

Earlier quoted context omitted.

> sudo apt-get install python3.10 python3.11 python3.12 This assumes the Python version you need is available from your package manager's repo. This won't work if you want a Python version either newer or older than what is available. > You are incorrect about needing to use an additional tool to install a "global" tool like `ruff`; `pip` does this by default when you're not using a virtual environment. True, but it'…

> This assumes the Python version you need is available from your package manager's repo. This won't work if you want a Python version either newer or older than what is available. And of course you could be working with multiple distros and versions of the same distro, production and dev might be different environment and tons of others concerns. You need something that just works across.

Surely you just use Docker for production, right?

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

#184

Post by ppierald »

poincaredisk wrote: post #14
nharada wrote: post #12

I really like uv, and it's the first package manager for a while where I haven't felt like it's a minor improvement on what I'm using but ultimately something better will come out a year or two later. I'd love if we standardized on it as a community as the de facto default, especially for new folks coming in. I personally now recommend it to nearly everyone, instead of the "welllll I use poetry but pyenv works or you…

I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?

Respectively, yes. The ability to create venvs so fast, that it becomes a silent operation that the end user never thinks about anymore. The dependency management and installation is lightning quick. It deals with all of the python versioning

and I think a killer feature is the ability to inline dependencies in your Python source code, then use: uv tool run

Your script code would like:

#!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.12" # dependencies = [ # "...", # "..." # ] # ///

Then uv will make a new venv, install the dependencies, and execute the script faster than you think. The first run is a bit slower due to downloads and etc, but the second and subsequent runs are a bunch of internal symlink shuffling.

It is really interesting. You should at least take a look at a YT or something. I think you will be impressed.

Good luck!

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

#185

Post by hamandcheese »

greatgib wrote: post #158

Ridiculous post: The author says that a normal route would be: - Take the proper route: - Create a virtual environment - pip install pandas - Activate the virtual environment - Run python Basically, out of the box, when you create an virtual it is immediately activated. And you would obviously need to have it activated before doing a pip install... In addition, in my opinion this is the thing that would sucks about U…

You can still use traditional venvs with UV though, if you want.

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

#186

Post by paularmstrong »

theogravity wrote: post #63
cdaringe wrote: post #41

Earlier quoted context omitted.

Hot take: pnpm is the best dx, of all p/l dep toolchains, for devs who are operating regularly in many projects. Get me the deps this project needs, get them fast, then them correctly, all with minimum hoops. Cargo and deno toolchains are pretty good too. Opam, gleam, mvn/gradle, stack, npm/yarn, nix even, pip/poetry/whatever-python-malarkey, go, composer, …what other stuff have i used in the past 12 months… c/c++ do…

pnpm is the best for monorepos. I've tried yarn workspaces and npm's idea of it and nothing comes close to the DX of pnpm

What actually, as an end user, about pnpm is better than Yarn? I've never found an advantage with pnpm in all the times I've tried it. They seem very 1:1 to me, but Yarn edges it out thanks to it having a plugin system and its ability to automatically pull `@types/` packages when needed.

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

#187

Post by lolinder »

benatkin wrote: post #120
nharada wrote: post #12

I really like uv, and it's the first package manager for a while where I haven't felt like it's a minor improvement on what I'm using but ultimately something better will come out a year or two later. I'd love if we standardized on it as a community as the de facto default, especially for new folks coming in. I personally now recommend it to nearly everyone, instead of the "welllll I use poetry but pyenv works or you…

This: > I haven't felt like it's a minor improvement on what I'm using means that this: > I'd love if we standardized on it as a community as the de facto default …probably shouldn’t happen. The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. It would be like replacing the python repl with the current version of ipython. I’d say the same thing, that it is…

> The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way.

The problem is that in the python ecosystem there really isn't a default de facto standard yet at all. It's supposed to be pip, but enough people dislike pip that it's hard as a newcomer to know if it's actually the standard or not.

The nice thing about putting something like this on a pedestal is that maybe it could actually become a standard, even if the standard should be simple and get out of the way. Better to have a standard that's a bit over the top than no standard at all.

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

#188

Post by benatkin »

lolinder wrote: post #187
benatkin wrote: post #120

Earlier quoted context omitted.

This: > I haven't felt like it's a minor improvement on what I'm using means that this: > I'd love if we standardized on it as a community as the de facto default …probably shouldn’t happen. The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. It would be like replacing the python repl with the current version of ipython. I’d say the same thing, that it is…

> The default and de facto standard should be something that doesn’t get put on a pedestal but stays out of the way. The problem is that in the python ecosystem there really isn't a default de facto standard yet at all. It's supposed to be pip, but enough people dislike pip that it's hard as a newcomer to know if it's actually the standard or not. The nice thing about putting something like this on a pedestal is that…

It feels even more standard than it used to, with python -m pip and python -m venv making it so it can be used with a virtalenv even if only python or python3 is in your path.

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

#189

Post by franktankbank »

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.

Why come types?

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

#190

Post by shlomo_z »

riwsky wrote: post #52

Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

Is it possible for my IDE (vscode) to support this? Currently my IDE screams at me for using unknown packages and I have no type hinting, intellisense, etc.
Post reply on HN